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SUMMARY 


The  objectives  of  this  study  were  to  develop  guidelines ,  mathematical  tools , 
and  procedures  that  can  be  used  by  equipment  designers  to  optimize  the  cost 
effectiveness  of  the  test  subsystem.  In  the  context  of  this  study,  the  term 
"test  subsystem"  refers  to  Built-In-Test  (BIT)  or  test  points  and  external  test 
equipment,  or  any  combination  thereof.  Specifically,  the  guidelines  and  pro¬ 
cedures  were  to  provide: 

•  Techniques  applicable  to  both  early  design  and  detailed  design  phases 

•  Techniques  which  are  applicable  to  the  design  of  test  subsystems  for 
both  avionics  and  ground  electronic  systems 

•  Mathematical  procedures  and  models  to  select  the  most  cost  effective  test 
subsystem  design,  taking  into  account  development,  production,  and 
total  life  cycle  costs. 

The  study  was  initiated  with  a  literature  search  and  evaluation  to  establish 
a  firm  technology  baseline  and  point  of  departure.  Two  significant  conclusions 
drawn  from  the  three-month  review  of  current  technology  were: 

•  The  terminology  and  parameters  relating  to  BIT,  test  diagnostics,  and 
fault  isolation  performance  have  proliferated,  are  frequently  used 
improperly,  or  are  misunderstood.  In  an  effort  to  avoid  such  confusion, 
this  report  includes  definitions  of  such  terms  and  parameters 

•  There  is  unanimous  agreement  among  the  authoritative  authors  and  the 
study  team  members  that  the  performance  of  the  test  subsystem  must  be 
specified  early  in  the  system  design  cycle,  i.e. ,  during  the  Conceptual 
Phase .  There  is  also  unanimity  that  the  driving  factors  in  selecting  the 
test  subsystem's  characteristics  (BIT  or  external  test  equipment  and  its 
performance ,  automatic ,  semi-automatic ,  or  manual)  are  the  prime  sys¬ 
tems  availability  requirements. 

However,  all  literature  reviewed  by  the  study  fails  to  provide  practical 


design  tools  to  relate  availability  to  test  subsystem  performance  and  life  cycle 
cost. 

Therefore ,  the  main  body  of  this  report  addresses  the  four  major  phases 
of  system  design  -  The  Conceptual  Design  Phase,  the  System  Design  Phase,  the 
Subsystem  Design  Phase,  and  the  Detailed  Design  Phase.  Each  section  addresses 
availability,  test  subsystem's  performance,  and  life  cycle  cost. 

CONCEPTUAL  DESIGN  PHASE 

The  major  objective  of  the  Conceptual  Design  Phase  is  to  select  optimum 
system  technologies  which  satisfy  mission  and  operational  requirements  within  a 
specified  cost  envelope.  Similarly,  the  test  subsystem  design  objective  is  to 
define  the  test  subsystem  technology  and  performance  requirements  within  the 
overall  cost  target.  To  do  this,  a  new  definition  of  test  subsystem  "effective¬ 
ness"  is  provided.  This  effectiveness  parameter  is  calculable  during  each 
design  phase  and  is  also  measurable  in  the  field.  There  is  a  complex  relation¬ 
ship  between  prime  system  availability  and  test  subsystem  effectiveness.  To 
complete  the  triad  necessary  to  specify  the  test  subsystem ,  the  relationships 
between  test  subsystem  effectiveness,  mean  active  repair  time,  reliability  and 
prime  system  life  cycle  cost  are  provided,  together  with  the  necessary  guide¬ 
lines,  procedures,  and  mathematical  design  tools. 

SYSTEM  DESIGN  PHASE 

Alternate  system  configurations  are  traded-off  considering  all  elements  of 
performance  and  cost.  The  test  subsystem  designer's  task  is  to  configure  an 
optimum  test  subsystem  for  each  candidate  prime  system  within  its  specified 
performance,  mean  time  to  repair,  and  life  cycle  cost.  The  mathematical  tools 
and  procedures  of  the  Conceptual  Design  Phase  are  equally  applicable  during  the 
System  Design  Phase ,  with  the  exception  that  they  are  applied  at  a  lower  level 
of  indenture.  Thus,  the  optimization  process  is  one  of  tailoring  the  test  sub¬ 
system  to  the  candidate  prime  system  characteristics. 

Two  major  issues  facing  the  test  subsystem  designer  during  this  phase  are 
evaluating  the  cost  impact  of  using  existing  subsystems  (with  less  than  adequate 
BIT)  vs  the  development  of  a  new  subsystem,  and  selection. of  the  BIT  architec¬ 
ture.  The  System  Design  Phase  Section  of  the  report  addresses  these  issues. 


SUBSYSTEM  DESIGN  PHASE 


Test  subsystem  capability  is  determined  by  the  number  and  quality  of  tests 
and  by  the  thoroughness  with  which  the  resulting  information  is  used.  For  this 
reason,  the  subsystem  design  methodology  optimized  the  choice  of  signals  mea¬ 
sured  and  quality  of  measurement  in  terms  of  information  gained  per  unit  of 
test  subsystem  cost .  These  parameters  are  calculated  individually  for  each 
signal,  traded  off  to  select  the  optimal  set  of  measurements,  and  summed  to 
calculate  resulting  test  subsystem  effectiveness  and  mean  corrective  maintenance 
times.  In  this  methodology,  the  optimal  test  subsystem  is  one  which  meets  or 
betters  effectiveness  and  mean  corrective  maintenance  time  requirements  of  the 
design  specification,  within  the  given  cost  envelope,  and  at  least  production 
cost. 

Initially ,  the  subsystem  is  analyzed  to  identify  functions ,  signals ,  and 
functional  paths,  and  this  information  is  recorded  in  functional  diagrams.  The 
signals  are  then  analyzed  in  terms  of  their  test  requirements  and  parameters, 
and  these  data  are  recorded  in  matrix  format.  Both  the  diagrams  and  matrices 
are  used  as  permanent  design  documents  that  identify  and  record  the  information 
developed  during  the  process  of  test  subsystem  design.  At  any  given  time, 
these  diagrams  and  matrices  provide  a  complete  architectural  and  parametric 
description  of  the  test  subsystem  at  its  current  stage  of  design  completion. 

Each  of  the  signals  listed  in  the  matrices  is  analyzed  to  determine  its  trade¬ 
off  merit  (worth)  in  terms  of  the  actual  testing  information  developed  versus  cost 
of  measurement.  Signal  measurements  of  least  worth  are  eliminated  to  the  degree 
necessary  to  ensure  that  the  evolving  design  remains  within  its  production  cost 
envelope.  Effectiveness  and  mean  corrective  maintenance  time  are  calculated, 
compared  with  specified  values,  and  the  design  is  reiterated  as  necessary  to 
comply  with  the  subsystem  design  specification.  These  trade-offs  and  design 
iterations  occur  in  parallel  with  the  mainstream  subsystem  design  effort ,  and 
reach  completion  when  the  main  effort  is  completed.  The  signal  matrices  and  test 
subsystem  design  are  then  expressed  in  LRU  design  specifications. 

DETAILED  DESIGN  PHASE 

The  principal  additional  design  effort  undertaken  during  detailed  LRU 
design  is  to  calculate  final  values  of  measurement  quality  by  analysis  of  actual 
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circuit  failure  modes  and  frequencies.  From  these  results,  effectiveness  and 
mean  corrective  maintenance  times  are  recalculated.  If  necessary,  the  test 
subsystem  design  is  adjusted  to  bring  it  into  compliance  with  the  effectiveness 
and/or  mean  corrective  maintenance  times  of  the  LRU  design  specification. 

Because  effectiveness  and  mean  corrective  maintenance  time  may  be  actually 
measured  in  deployed  systems,  the  results  of  test  subsystem  design  calculations 
and  signal  matrices  are  saved  for  reference. 

STUDY  CONCLUSIONS  AND  RECOMMENDATIONS 

The  study  objective  to  develop  straightforward  engineering  tools  which  per¬ 
mit  optimization  of  the  test  subsystem  design  during  the  overall  system  design 
phase  and  also  during  the  detailed  design  phase  has  been  met.  During  the  con¬ 
ceptual  and  system  design  phases ,  the  test  subsystem  must  be  specified  in  realistic 
performance  and  cost  parameters  depending  on  the  prime  system's  mission,  op¬ 
erational  and  support  concepts.  Using  the  guidelines  and  design  procedures 
provided ,  these  parameters  will  fall  within  the  following  ranges : 

•  Test  subsystems  Effectiveness  (ET>  =  75%  to  95% 

•  Mean  Corrective  Maintenance  Time  (Mct)  =  30  minutes  to  4  hours 

•  Reliability  of  BIT  (R_T„)  -  less  than  10%  of  the  prime  system's  overall 

JdI  1 

failure  rate  due  to  BIT 

•  Design-to-cost  target  for  the  Test  Subsystem  =  10%  to  20%  of  the  prime 
system's  production  costs 

By  designing  to  the  above  parameters  during  each  phase  of  system  design  (using 
the  study  equations  and  models)  an  optimized  test  subsystem  will  be  achieved. 

The  resultant  test  subsystem's  performance  will,  at  best,  be  less  than  per¬ 
fect.  This  is  due  to  the  fact  that  hardware  and/or  software  designers  are  faced 
with  an  inaccurate  knowledge  of  what  will  fail  and  how  often.  Thus  the  major 
study  recommendations  are  that  the  test  subsystem  must  be  tested  and  demon¬ 
strated  in  the  field,  prior  to  full-scale  production.  Further,  a  tracking  and 
analysis  system  for  all  no  defect  removals  will  materially  reduce  the  reported 
number  of  false  alarms  and  significantly  improve  system  availability. 
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It  is  recommended  that  further  subject  related  studies  of  existing  military 
data  sources  and  design  reporting  systems  be  performed.  The  objective  would  be 
to  provide  filtered  data  bases ,  and  a  procedural  handbook  to  implement  the  ap¬ 
plication  of  the  recommended  design  guidelines  and  procedures  advanced  in  this 
report . 


PREFACE 


This  technical  report  presents  the  results  of  a  study  to  develop  design 
guidelines  and  optimization  procedures  for  test  subsystem  designs.  The  study 
was  performed  under  Contract  F  30602- 78-C- 0167.  This  report  is  prepared  in 
accordance  with  CDRL  item  A002  and  data  item  description  DI-S-3591A/M. 

The  guidelines  and  optimization  procedures  detailed  in  this  report  satisfac¬ 
torily  achieve  the  objectives  of  the  study. 
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EVALUATION 


1.  The  objective  of  this  study  was  the  investigation  and  development  of 
optimization  tools  and  algorithms  that  can  be  used  during  the  design  phases 
of  a  test  subsystem,  to  aid  in  forming  the  most  cost  effective  design 
configuration.  The  developed  techniques  were  to  take  into  account  prime 
system  failure  rates,  and  test  subsystem  characteristics  such  as  fault 
detect ion/ isolation  capabilities,  false  alarm  rates,  production  costs  and 
life  cycle  costs. 

2.  The  methodology  developed  herein  satisfactorily  achieves  the  object¬ 
ives  for  which  it  was  intended.  The  methodology  is  applicable  to  all 
phases  of  the  design  of  test  subsystems.  The  study  contains  realistic 
design  guidelines  pertaining  to  the  development  of  cost  effective  test 
subsystems.  The  optimization  procedure  is  structured  to  systematically 
produce  specified  fault  detection  and  isolation  levels  within  a  specified 
cost  envelope. 

3.  The  design  and  development  of  effective  test  subsystems  is  a  critical¬ 
ly  important  task  in  the  effort  to  reduce  the  support  costs  associated  with 
modern  defense  systems.  The  output  of  this  study  contributes  to  that  end 
and  will  be  used  as  input  to  future  acquisition  guides  for  test  support 
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1.  INTRODUCTION 


Although  there  is  a  consensus  that  weapon  systems  and  ground  electronic 
systems  maintenance  and  logistic  costs  are  excessive ,  there  is  seldom  agreement 
as  to  the  causes.  Built-In-Test  (BIT)  is  a  singular  exception.  The  overwhelm¬ 
ing  evidence  is  that  BIT  performance  has  fallen  far  short  of  expectations.  As 
a  major  cost  driver,  the  failure  of  BIT  to  detect  and  fault -isolate  impacts  the  en¬ 
tire  spectrum  of  maintenance  and  logistic  costs .  The  objective  of  this  study  is 
to  develop  optimization  tools  and  algorithms  that  can  be  used  to  select  the  most 
cost-effective  BIT  designs. 

1.1  SCOPE 

Systematic  methodologies  and  procedures  for  the  design  of  BIT  subsystems 
for  avionic  and  ground  electronics  are  to  be  developed.  These  techniques  are  to 
take  into  account  the  failure  rate  of  each  isolatable  module,  the  total  proportion 
of  equipment  faults  that  the  BIT  subsystem  will  recognize,  the  life  cycle  costs 
associated  with  fault  detection  and  isolation  of  each  failure,  false  alarm  character¬ 
istics  ,  and  the  resulting  impact  on  equipment  maintainability.  All  these  factors, 
in  combination,  are  to  be  used  to  guide  the  design  of  BIT  subsystems 

The  quantitative  requirements  for  a  BIT  subsystem  are  so  inextricably  woven 
into  the  prime  system  cost  effectiveness  equation  that  the  determination  of  "how 
much  and  where"  must  be  made  as  an  integral  part  of  the  system  design  process. 
To  optimize  the  BIT  subsystem,  its  performance  requirements  must  be  analyzed 
and  specified  to  the  appropriate  level  during  each  phase  of  design.  The  only 
viable  approach  to  deriving  a  systematic  methodology  is  to  include  all  phases  of 
system  design  which  are:  the  Conceptual  Design  Phase,  the  System  Design 
Phase,  the  Subsystem  Design  Phase,  and  the  Detailed  Design  Phase  as  shown  by 
Fig.  1-1. 
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rig.  1-1  T«t  Subryitsm  Dasign  Optimization  Procadura 


1.2  BACKGROUND 


In  present  day  military  electronics ,  more  and  more  use  is  being  made  of 
BIT  to  aid  in  maintenance.  BIT  usually  makes  it  possible  to  have  fewer  and 
less  qualified  maintenance  personnel  and  less  external  test  equipment.  How¬ 
ever,  even  though  the  use  of  BIT  is  rapidly  expanding,  little  research  has  been 
done  to  aid  designers  in  how  to  apply  BIT  and  diagnostics  in  a  cost-effective 
fashion . 

1.3  LITERATURE  SEARCH 

The  initial  study  task  was  to  perform  a  thorough  literature  search  and  re¬ 
view  existing  technology  to  establish  a  state-of-the-art  baseline  from  which  the 
required  BIT  design  procedures  and  diagnostic  methodologies  could  be  selected 
or  developed. 

Starting  with  an  initial  list  of  44  books,  articles,  reports,  and  specifica¬ 
tions,  the  study  library  grew  to  more  than  100  reference  documents.  Most  of 
these  documents  addressed  procedures  and  methodologies  to  optimize  a  particular 
facet  of  detailed  BIT  circuit  design.  A  few  addressed  the  subject  of  test  sub¬ 
system  optimization  procedures,  giving  general  guidelines  and  "do's  and  don'ts" 
rather  than  quantitative  data,  mathematical  tools,  and  trade-off  procedures. 

The  documents  and  specifications  which  were  most  relevant  and  which 
formed  the  study  baseline  are  listed  in  Fig.  1-2,  together  with  the  Design 
Phase  addressed  by  that  document. 

Following  Section  5  is  a  Bibliography  of  all  references  which  are  quoted  or 
used  in  preparing  this  final  report  (see  page  175) . 

1.4  TECHNICAL  PROBLEMS 

The  review  of  current  military  literature,  specifications,  and  handbooks  in¬ 
dicates  that  the  fundamental  principles  of  BIT  design  and  optimization  are  fre¬ 
quently  misunderstood  or  have  not  received  adequate  attention  in  the  early 
phases  of  system  design.  In  most  cases,  the  first  indication  that  performance 
requirements  will  not  be  met  comes  during  the  Full  Scale  Development  Phase. 

In  some  cases  additional  funds  are  allocated  to  achieve  improvements,  such  as 
greater  reliability  and  effectiveness.  In  many  cases,  however,  the  BIT  require- 
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ments  are  simply  lowered  and  the  BIT  system  accepted  without  consideration  of 
the  resulting  increase  in  maintenance  and  logistic  costs. 

The  fundamental  question  to  be  answered  by  the  study  is,  therefore,  "How 
much  funding  should  be  expended  to  achieve  what  degree  of  BIT  capability  to 
meet  the  overall  mission  requirements?" 

1.4.1  Specifying  BIT  Effectiveness 

The  effectiveness  of  BIT  has  been  specified  for  avionics  in  AR-10A  as: 
"3.3.3  Built  in  Test  (BIT)  Dependability  -  The  BIT  features  shall  be  such  that 
at  least  98%  of  the  equipment  failures  shall  be  detected .  At  least  99%  of  the  de¬ 
tected  failures  shall  be  located  to  the  faulty  WRA.  At  least  99%  of  the  failure 
indications  shall  result  from  equipment  failures  (performance  below  acceptable 
levels)."  Also:  "3. 4. 2. 2  Non-Ambiguity  (N-A)  Ratio  -  The  ratio  of  the  number 
of  probable  malfunctions  detected  and  isolated  directly  to  the  WRA  with  built-in- 
test  features  without  ambiguity,  to  the  total  number  of  probable  malfunctions, 
shall  not  be  less  than  0.97  unless  otherwise  specified  in  the  detail  specification. 
An  example  of  this  computation  is  shown  in: 

Non- ambiguity  (N-A)  ratio  =  Number  of  probable  malfunctions  isolated  di¬ 
rectly  to  faulty  WRA /Total  number  of  probable  malfunctions" 

BIT  dependability  and  non-ambiguity  as  specified  above  are  subject  to  in¬ 
terpretation,  difficult  (if  not  impossible)  to  measure  in  actual  operations,  and 
seldom,  if  ever,  achieved. 

Generalized  maintainability  and  BIT  requirements  such  as  contained  in 
AR-10A  represented  a  significant  step  forward  in  1969.  However,  the  results 
of  specifying  either  the  "best  that  we  can  hope  for"  or  "utopia"  without  regard 
to  life  cycle  cost  is  not  acceptable  today.  Rather,  to  optimize  BIT,  it  must  be 
specified  in  terms  that  are  calculable  during  the  systems  engineering  process 
and  also  measurable  during  system  test,  evaluation,  and  deployment. 

The  problem  of  specifying  test  effectiveness,  (i.e.,  fault  detection  and 
isolation  capability)  for  either  BIT  or  external  test  equipment  is  complicated  by 
the  rapidly  advancing  state-of-the-art.  The  recorded  performance  of  existing 


test  subsystems  in  the  field  (when  available)  is  at  best  an  inadequate  measure  of 
how  much  fault  detection  and  isolation  performance  can  be  achieved. 

Of  equal  importance,  the  problem  of  relating  the  BIT  performance  specifi¬ 
cation  to  its  impact  on  system  complexity ,  reliability ,  maintainability ,  and  LCC 
remains  virtually  unaddressed  in  the  current  literature.  Therefore,  the  deriva¬ 
tion  of  means  to  specify  BIT  effectiveness  is  considered  a  prime  objective  of  the 
study . 

1.4.2  The  BIT  "Cost  Data”  Problem 

Life  cycle  cost  data  are  generally  acknowledged  to  be  elusive  and  inac¬ 
curate.  Cost  data  for  BIT  are  virtually  non-existent  since  they  are  not  an  iden¬ 
tifiable  subsystem  within  the  work-breakdown-structure  (WBS)  cost  accounting 
system.  With  the  exception  of  item  10  of  Fig.  1-2,  no  substantive  BIT  cost  data 
were  found.  While  the  "BIT  LCC  Trade-off  Model"  of  Appendix  A  is  an  excellent 
vehicle  for  the  collection  of  engineering  estimates  of  LCC  during  the  Design 
Phase,  ihere  is  no  apparent  means  to  collect  actual  expended  cost  data  for  BIT 
hardware  and  software. 

1.4.3  BIT  "Performance  Data"  Problem 

The  basic  objective  of  BIT  or  external  testing  is  to  detect  and  isolate 
equipment  malfunctions  to  a  replaceable  unit.  The  measure  of  BIT  performance, 
it  would  seem,  is  straightforward  and  could  be  recorded  into  the  AFR  66-1/65-110 
data  system .  However ,  the  following  issues  complicate  the  recording  of  such 
data: 

•  False  Alarms  -  in  which  BIT  falsely  identifies  an  LRU  as  a  malfunction¬ 
ing  unit  where,  in  fact,  there  is  no  malfunction 

•  BIT  Diagnostic  Errors  -  in  which  BIT  incorrectly  isolates  an  actual 
fault  to  one  or  more  non-malfunctioning  LRUs 

•  Undetected  Failures  -  in  which  BIT  fails  to  detect  a  malfunctioning  LRU 

•  BIT  Ambiguity  -  in  which  BIT  detects  a  fault  and  correctly  isolates 
to  two  or  more  LRUs 

•  Intermittents  -  in  which  an  electrical  malfunction  is  present  only  at  cer¬ 
tain  times,  and  which  at  all  other  times  appears  to  be  a  false  alarm. 


This  report  addresses  all  of  the  above  issues  and  their  impact  on  the  test 
subsystem  design.  However,  these  problems  are  not  reported  in  the  AFR  66-1/ 
65-110  or  the  Navy  3M  maintenance  data  systems.  They  can  and  should  be  in¬ 
cluded  in  a  maintenance  action  tracking  and  analysis  system  to  permit  quantita¬ 
tive  recording  of  their  existence ,  analysis  of  their  causes ,  and  identification  of 
corrective  actions. 


1.5  GENERAL  METHODOLOGY 


The  DoD  Acquisition  Process  emphasizes  cost  effectiveness  and  reduction 
of  risk  through  validation,  demonstration,  and  hardware  proofing  prior  to  pro¬ 
duction  commitment.  The  process  is  one  of  optimizing  the  total  system  design. 
The  "test  subsystem"  is  an  integral  part  of  each  system,  subsystem,  and  LRU-, 
and  as  such  is  not  a  uniquely  identifiable  subsystem.  However,  the  term  is 
useful  in  referring  to  the  test  points,  BIT  hardware  and  software,  perform¬ 
ance  monitor,  and  external  test  equipment  and  will  be  used  in  that  context 
throughout  this  report. 

During  the  early  system  design  phase,  the  engineering  design  progresses 
iteratively  in  increasing  detail  with  the  outputs  of  the  preceding  phase  serving 
as  the  design  requirements  for  the  next  phase.  During  these  early  phases  the 
system  designer  requires  mathematical  tools  for  use  in  determining  the  optimum 
test  subsystem  (BIT  or  external),  the  degree  of  fault  isolation  to  be  achieved, 
and  a  valid  projection  of  the  resulting  LCC  benefits. 

During  the  detailed  design  phase,  the  designer,  who  must  implement  actual 
hardware  and  software,  requires  similar  mathematical  tools  tailored  to  his  own 
disciplines.  The  cost /benefit  aspect  of  his  design  must  be  weighed  against  its 
capability  to  detect  and  isolate  faults.  This  means  he  needs  a  methodology  to 
allocate  BIT  functions  to  those  locations  in  his  design  where  benefits  are  maxi¬ 
mum  per  unit  of  life  cycle  cost . 

The  general  methodology  of  the  study  then ,  is  to  address  each  phase  of  the 
system  design  cycle  and  provide  optimization  tools  and  procedures  based  on  the 
evaluation  and  analysis  of  current  literature  and  Grumman  test  subsystems  de¬ 
sign  experience. 

Because  it  is  important  that  the  tools  and  procedures  be  readily  usable,  we 
have  performed  a  verification  that  simulated  their  application  to  an  existing  avi¬ 
onics  subsystem  E-2C  Advanced  Radar  Processing  System  (ARPS)  of  the 
AN /APS- 125  Radar  System.  (See  Appendix  C  -  Application  of  the  Test  Subsys¬ 
tem  Optimization  Procedures). 
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1.5.1  Study  Approach 

The  design  of  a  new  system  and  the  optimization  of  its  test  subsystem  is  an 
evolutionary  process.  Development  proceeds  in  an  orderly  progression  of  sys¬ 
tem  engineering  during  the  System  Acquisition  Cycle,  starting  with  the  Con¬ 
ceptual  Phase  through  the  Production  Phase  as  shown  in  Fig.  1-3.  Optimization 
is  achieved  by  applying  the  proven  systems  engineering  methods  of  AFSCM 
375-5  to  the  prime  and  subsystem  designs  to  achieve  a  balance  and  depth  of  en¬ 
gineering  effort  during  each  phase. 

The  study  approach  has  been  influenced  by  our  conviction  that  the  opti¬ 
mization  of  a  system  or  subsystem  design  is  best  achieved  through  strict  adher¬ 
ence  to  the  DoD  system  design  procedures.  The  system  engineering  methods  of 
AFSCM  375-5  and  AFSCP  800-3,  and  the  engineering  management  processes  of 
MIL-STD-499A  (USAF),  as  tailored  to  meet  the  needs  of  each  program,  provide 
the  necessary  methodology  and  management  procedures  to  optimize  the  prime 
system  design,  including  the  test  subsystem.  Therefore,  the  study  identified 
procedures  consistent  with  the  above  referenced  documents. 

1.5.2  Fundamental  Test  Subsystem  Optimization  Concepts  and  Guidelines 

The  following  concepts  and  guidelines  are  based  on  the  review  and  evalua¬ 
tion  of  current  literature,  and  Grumman  exnerience  in  system  design. 

Early  specification  of  test  subsystem  performance  requirements  and  cost  objectives  is 
necessary. 

Early,  in  this  case,  means  during  the  Conceptual  Design  Phase.  In  the 
past,  failure  to  specify  these  parameters  early  enough  has  led  to  a  test  capabil¬ 
ity  that  is  sacrificed  to  achieve  either  greater  prime  system  performance,  re¬ 
duced  production  cost,  or  both. 

Optimization  of  built-in  test  must  be  accomplished  by  optimizing  the  system  design. 

BIT  functions  are  not  only  inseparable  from  the  prime  mission  functions 
of  the  system  but  are  also  critical  to  the  performance  of  that  mission.  For  ex¬ 
ample,  if  the  BIT  component  or  software  fails,  then  the  subsystem  or  LRU  has 
failed  since  it  can  no  longer  perform  as  designed.  BIT  should  not  be  deemed  an 
entity  that  exists  separately  from  the  system's  primary  function  and  equipment. 


SYSTEM  ACQUISITION  CYCLE 


Relationship  Between  the  System  Acquisition 
i  System  Design  Cycle 


The  performance  of  the  test  subsystem  must  be  specified  in  parameters  which  are  ob¬ 
servable,  measurable,  and  reportable  in  field  operation. 

The  parameters  should  be  equally  applicable  to  BIT,  external  test  equip¬ 
ment,  and  built-in-test  equipment. 

The  analysis  and  design  of  the  test  subsystem  must  include  all  components  and  all  known 
failure  modes. 

It  will  be  shown  that  the  test  subsystem  performance,  at  its  best,  will  be 
far  from  perfect. 

The  test  subsystem  must  be  treated  as  a  high  risk  element  of  the  system  design. 

The  abilities  of  the  circuit  design  engineer,  the  reliability  engineer,  and 
the  maintainability  engineer  are  severely  taxed  to  perform  a  thorough  failure 
mode  and  effects  analysis  (FMEA).  It  is  improbable  that  a  test  subsystem  can 
be  designed  to  detect  all  possible  malfunctions  or  to  incorporate  the  infallible 
logic  necessary  for  isolation  to  a  single  replaceable  unit.  Errors  in  paper  analy¬ 
sis  are  magnified  by  the  inability  of  the  analyst  to  accurately  predict  the  fre¬ 
quency  of  operational  failures .  Thus ,  the  hardware  and  software  designers 
are  faced  with  an  inaccurate  knowledge  of  what  will  fail ,  and  how  often  it  will 
fail. 

Other  factors  lead  to  the  conclusion  that  the  test  subsystem  is  inherently 
a  high  risk  design  element: 

•  Intermittents  cannot  be  readily  isolated  with  state-of-the-art  test  sub¬ 
systems  (See  Appendix  D) 

•  Multiple  faults  cannot  be  accurately  predicted  or  isolated  with  state-of- 
the-art  test  subsystems 

•  'Wiring  harness  and  connector  faults  are  generally  not  susceptible  to 
BIT. 

The  study  procedures  and  optimization  tools  presented  herein  provide  a 
method  of  quantifying  some  of  the  above  problems.  The  approaches  taken  in  the 
study  were  to  recognize  that  these  problems  exist,  determine  the  elements  of 
risk  that  they  impose,  and  identify  means  to  correct  remaining  design  problems. 


Early  test  and  evaluation  is  required  to  optimize  the  test  subsystem. 

The  time-phased  relationship  between  the  System  Acquisition  Cycle  and 
the  Design  Cycle  for  new  systems  is  shown  in  Fig.  1-3.  Early  prototype  test 
and  evaluation,  during  full  scale  development,  is  necessary  for  all  complex, 
newly  designed  systems  and  subsystems.  This  will  reduce  the  high  risk  ele¬ 
ments  of  test  subsystems  with  extensive  BIT .  Test  and  evaluation  is  necessary 
to  identify  and  resolve  the  problems  listed  in  the  previous  paragraph  and  the 
following  additional  problems  which  are  not  readily  identified  during  the  design 
process : 

•  BIT  logic  problems  associated  with  multiple  subsystem  interfaces 

•  Signal  tolerance  problems  which  occur  only  when  subsystems  are 
married  and  operated  as  a  system 

•  Operator  and  BIT  human  interface  problems  which  cannot  be  predicted 
except  in  actual  operation 

•  Maintenance  personnel  and  BIT  interface  problems  which  cannot  be 
predicted  except  in  actual  operation. 

The  prototype  test  and  evaluation  hardware  must  be  close  enough  to  the 
production  system  configuration  to  validate  the  BIT  performance  requirements 
specified  in  the  Allocated  Baseline  Configuration  Items  (Cl)  Specification. 
Changes  and  modifications  to  achieve  the  specified  performance  are  incorporated 
in  the  Product  Baseline  and  Production  Cl  Specifications. 

To  assure  the  quality  of  production  BIT,  formal  qualification  testing  is  re¬ 
quired  to  demonstrate  BIT  performance.  This  requirement  will  ensure  that  BIT 
is  utilized  in  maintenance  of  the  prime  system  from  its  initial  operation  to  its 
operational  deployment . 

1.6  DEFINITION  OF  SELECTED  TERMS  AND  PARAMETERS 

Definitions  of  common  terms  used  in  this  report  may  be  found  in  MIL-STD- 
1309  and  MIL-STD-721.  The  definitions  and  discussions  that  follow  involve  se¬ 
lected  ternm  whose  meaning  is  unique  to  the  study  and/or  which  are  frequently 
subject  to  misinterpTetation . 


1.6.1  System 

The  study  addressed  the  design  of  BIT  and  test  equipment  to  support  avi¬ 
onic  and  ground-based  electronic  systems.  The  term  "system"  will  therefore 
refer  to  avionic  and  ground  electronic  equipment  including  it  j  built-in  test  and/ 
or  test  equipment.  When  referring  to  the  total  weapon  or  ground  system  (e.g. , 
F-15,  F-4D,  AN/FPS-27),  the  terms  "prime  system"  or  "host  system"  will  be 
used.  The  procedure  for  BIT  optimization  will  generally  be  applicable  to  both 
major  or  large  scale  system  designs  and  to  small  scale  systems  except  as  noted  in 
the  text. 

1.6.2  Subsystem 

This  term,  as  used  in  the  study,  denotes  either  a  single  equipment  or  a 
group  of  electronic  equipments  whose  functions  are  interrelated  within  the  group, 
but  relatively  isolated  from  those  of  other  groups: 

•  Flight  Controls  and  Displays 

•  Communication,  Navigation,  Identification  (CNI) 

•  Weapon  Control 

•  Weapon  Delivery 

•  Electronic  Countermeasures . 

The  definition  of  avionic  subsystems  will  vary  dependent  upon  the  aircraft 
mission  and  the  avionic  system's  design  characteristics  (i.e.,  attack,  fighter, 
bomber,  cargo)  or  the  degree  to  which  the  functions  are  integrated  (such  as  the 
CNI). 

Ground  electronic  subsystems  are  extremely  varied  in  function  and  com¬ 
plexity.  For  example,  referring  to  Fig.  1-4,  functional  subsvstems  would  be  at 
either  level  3  or  4,  dependent  upon  the  degree  of  autonomy.  Figure  1-4  also 
illustrates  the  interdependence  of  systems  and  subsystems  in  specifying  and 
achieving  operational  performance  and  maintainability  goals . 

1.6.3  Performance  Monitor /BIT  (PM /BIT) 

Performance  Monitoring  equipment  is  designed  to  detect  a  malfunction  within 
a  series  of  critical  functions.  The  monitoring  equipment  is  required  to  alert  the 
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Fig.  1-4  Functional  Laval  Breakdown  of  a  Hypothetical 
Ground  Electronic  System 


operator  of  a  failure  or  impending  failure .  Since  performance  monitoring  equip¬ 
ment  is  required  to  achieve  mission  requirements,  it  is  specified  as  one  of  the 
prime  system  functions. 

Both  hardware  and  software  are  required  to  control  system  operation  as 
well  as  monitor  performance.  The  performance  monitoring  function  is  accom¬ 
plished  using  a  multiplicity  of  sensors ,  displays ,  computer  programs ,  and ,  in 
many  cases,  built -in-test  equipment.  The  relation  between  the  monitor  function 
and  BIT  is  complex  and  in  many  cases  overlapping. 

In  this  report  BIT  is  defined  as  hardware  and  software  added  to  the  prime 
system  for  the  sole  purpose  of  detecting  and  isolating  a  malfunction  to  a  re¬ 
placeable  unit.  BIT  does  benefit  from  the  overlap  of  Performance  Monitoring 
capabilities.  While  the  system  designer  will  seek  to  optimize  both  BIT  and  Sys¬ 
tem  Performance  Monitoring  as  a  single  integrated  test  subsystem,  the  cost  and 
capabilities  of  the  Performance  Monitoring  equipment  cannot  be  traded  off  or  de¬ 
graded  . 

The  following  ground  rule  applies  to  the  system  analyst  when  dealing  with 
the  obvious  overlap  of  Performance  Monitoring  and  BIT  (PM/BIT) .  They  will  be 
treated  as  a  single  combined  function  whose  cost  and  performance  is  specified 
and  designed  as  a  single  entity.  However,  during  trade-off  studies  (e.g.,  BIT 
vs  external  test  equipment)  the  costs  of  each  (PM  and  BIT)  must  be  estimated 
as  separate  entities  and  only  the  cost  of  BIT  hardware  will  be  considered  in  the 
trade  studies. 

1.6.4  Mission  Cost  Effectiveness 

During  the  Conceptual  Phase,  the  analyst  must  evaluate  alternative  system 
configurations  to  achieve  the  desired  Mission  Effectiveness  (E)  at  the  lowest  LCC. 

r 

The  interrelationship  of  prime  system  cost  and  effectiveness  j-is  described  by: 


where  P  =  Performance ,  A  =  Operational  Availability ,  R  =  Mission  Reliability , 

S  =  Mission  Survivability,  and  LCC  =  The  Life  Cycle  Cost  of  the  total  system  or 
subsystem . 


The  systems  analyst  must  make  both  quantitative  and  qualitative  judgments 
of  the  technological,  military,  and  economic  feasibility  of  the  total  system.  The 
analysis  and  modeling  of  mission  performance  and  survivability  parameters  are 
not  a  subject  of  this  study.  However,  the  MTBF  used  to  calculate  operational 
availability  is  impacted  by  BIT  hardware  and  software. 

The  reliability  of  the  cost  effectiveness  equation  is  the  mission  reliability: 


D  -t/MTBF 
R  =  e  o 


(Eq.  2) 


where  t  =  mission  time,  and  MTBFQ  =  Operational  mean  time  between  failure. 


The  reciprocal  of  MTBF0  is  the  mission  failure  rate: 
*  *  prime  system  +  ^BIT 


(Eq.  3) 


Operational  availability  is  the  unconditional  probability  that  the  system  will 
be  capable  of  operating  at  or  above  a  specified  level  of  performance  if  called  upon 
to  do  so  at  a  random  point  in  time : 


MTBF0 


MTBFq  +  MDT0 


(Eq.  4) 


where  MDT0  =  mean  downtime,  including  active  repair  time,  administrative  time, 
and  logistic  delay  time.  Mean  downtime  is  expressed  as: 


MDT0  -  MC{  +  +  Ma  +  Mpt 


(Eq.  5) 


where  =  mean  corrective  maintenance  time  (active  repair  time),  =  mean 
logistic  delay  time,  M  =  mean  administrative  delay  time,  and  M  =  mean  pre- 
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ventive  (scheduled)  maintenance  time  and  technical  modification  time. 

Thus,  MDT0  partly  determines  a  prime  system  or  subsystem's  turnaround  time 
(TAT).  When  combined  with  operational  reliability,  it  defines  the  system  or  sub¬ 
system's  operational  availability. 

The  remaining  term  of  the  effectiveness  equation  (LCC)  is  also  impacted  by 
BIT.  The  classic  elements  of  LCC  as  specified  by  DoD  are: 

•  RDT&E 

•  Acquisition  Cost  (which  includes  Design,  Production,  and  Initial  Support 
Costs) 


•  Operation  and  Support  (O&S)  Costs. 

These  will  be  further  defined  in  the  sections  that  follow. 

1.6.5  Inherent  Availability 

Inherent  availability  is  the  conditional  probability  that  a  system  or  equip¬ 
ment  will  be  capable  of  operating  at  or  above  a  specified  level  of  performance  if 
called  upon  to  do  so  at  a  random  point  in  time,  given  that  there  is  no  waiting 
time  for  spares  or  delays  before  or  during  a  maintenance  action.  This  definition 
relates  the  readiness  of  the  system  or  equipment  to  its  inherent  design  character¬ 
istics  and  does  not  penalize  the  readiness  assessment  due  to  logistic  shortages 
or  administrative  delays.  Inherent  availability,  then,  is  the  value  which  would 
be  achieved  under  ideal  conditions.  It  is  defined  as: 


A.  =  MTBF 
1  MTBF  +  Mct 


(Eq.  6) 


where  MTBF  =  the  calculated  mean  time  between  failure,  and  Mct  =  the  mean 
corrective  maintenance  time. 

1.6.6  Corrective  Maintenance  Time  and  Mean  Time  to  Repair 

The  terms  Mcti,  Mcti,  and  Mct  will  be  used  throughout  this  report.  To  avoid 
confusion,  the  abbreviation  MTTR  often  denoted  as  Mct  will  not  be  used.  The 
following  definitions  will  be  used: 

•  Corrective  Maintenance  Action  -  the  action  required  to  repair  a  single 
failure,  comprised  of  all  those  individual  maintenance  tasks  (e.g.,  fault 
localization,  isolation,  repair,  checkout,  etc.)  involved  in  the  maintenance 
procedure.  A  maintenance  event  is  comprised  of  one  or  more  maintenance 
actions  required  to  repair  all  failures  associated  with  an  equipment 
malfunction 

•  Individual  Corrective  Maintenance  Task  Time  (Mcti)  -  the  time  required 
to  complete  an  individual  maintenance  task  or  an  individual  maintenance 
action.  Individual  maintenance  task  or  maintenance  action  times  ob¬ 
served  during  a  test,  for  example,  would  be  denoted  as  Mcti*  When 
maintenance  time  estimates  are  based  on  an  average  of  several  observa- 
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tions,  as  used  in  prediction  analysis  for  example,  individual  maintenance 
task  or  action  times  are  denoted  by  Mcti  to  indicate  that  the  value  is  an 
average  value  for  the  individual  task  or  action.  The  following  notations 
for  individual  corrective  maintenance  time  are  used  throughout  and  are 
interchangeable  in  the  equations  in  which  they  appear: 

-  Mctj  =  corrective  maintenance  required  to  complete  the  ith  individual 
maintenance  task  or  action,  based  on  a  single  observation 

2  Mcti 

-  Mct-  = - =  average  corrective  maintenance  time  required  to  complete 

N 

the  ith  individual  maintenance  task  or  the  ith  individual 
maintenance  action,  averaged  over  several  (e.g.,  N) 
observations  for  the  same  (ith)  task  or  action 

•  Mean  corrective  m.  *enance  time  (ivi  )  -  the  mean  time  required  to  com¬ 
plete  a  maintenance  action,  i.e.,  the  total  maintenance  downtime  divided 
by  the  total  maintenance  actions,  over  a  given  period  of  time.  Mean 
corrective  maintenance  time  is  defined  by  MIL-STD-471  as  the  summation 
of  all  maintenance  downtime  during  a  given  period  divided  by  the  number 
of  maintenance  actions  during  the  same  period  of  time,  given  as: 


Mct  -  £<‘l  Mct.> 


(Eq.  7) 


where  X  j  =  failure  rate  of  the  individual  (ith)  element  of  the  item  for  which  main¬ 
tainability  is  to  be  determined,  adjusted  for  duty  cycle,  catastrophic  failures, 
tolerance  and  interaction  failures ,  etc . ,  which  will  result  in  deterioration  of  item 

performance  to  the  point  that  a  maintenance  action  will  be  initiated  and  M  .  ,  in 

Cli 

this  case  is  the  average  repair  time  required  to  correct  the  ith  repairable  element 
in  the  event  of  itr.  failure. 

1.6.7  As-Designed  MTBF  vs  MTBF0 


MTBF0  is  the  achieved  apparent  failure  rate  as  reflected  in  AFR-66- 1/65-110 
data.  It  is  expressed  as: 


MTBF0  = 


Sum  of  operating  hours  for  all  systems 

Sum  of  all  maintenance  actions  due  to  an  indicated  malfunction 


where  the  number  of  maintenance  actions  includes  "No-Defect  Removals"  (R^), 
"Repair  in  Place"  (C),  and  "Remove  and  Replace"  (Rr>. 

The  ratio  of  as-designed  MTBF  to  operational  MTBFq  is  a  heuristic  K  factor 
and  will  vary  greatly  according  to  system  characteristics,  maintenance  policy, 
operational  use  of  the  equipment,  and  quality  of  maintenance.  In  general,  the 
K  factor  represents  the  difference  between  the  average  (benign)  environment 
for  which  MTBF  is  calculated  and  the  actual  multiplicity  of  environments  (harsh) 
encountered  for  all  operational  systems.  The  K  factor  also  accounts  for  the  very 
real  problems  of  maintenance  induced  failures,  variable  duty  cycles,  ground 
operate  and  off-line  operate  time,  full  systems  capability  vs  alternate  operational 
modes,  etc.  Regardless  of  the  rationale,  the  K  factor  is  very  real  as  detailed 
below  and  must  be  used  when  converting  from  the  as-designed  MTBF  to  the 
operational  MTBFq. 

The  following  text  and  Fig.  1-5  are  excerpted  from  AFLCP  800-3,  "Logistic 
Performance  Factors  in  Integrated  Logistic  Support,"  19  April  1973,  Section  C, 
"Life  Cycle  Trends  of  Logistics  Performance  Factors,"  Pages  27,  28,  and  29. 

"It  is  common  knowledge  there  is  poor  correlation  between  operational  and 
design  or  test  reliability.  There  is,  however,  a  difference  of  this  relationship. 
Many  efforts  have  been  made  to  compare  operational  MTBF  with  design  MTBF 
and  to  determine  why  the  lack  of  correlation.  Results  of  these  efforts  have  been 
the  identification  of  reasons  why  they  are  different  and  the  development  of 
conversion  or  K  factors  by  which  to  convert  from  one  to  the  other.  There  are 
two  categories  of  reasons  for  the  difference;  those  that  management  can  do 
something  about,  and  those  that  are  not  subject  to  alteration  by  management. 

In  addition  to  correcting  the  first ,  all  agencies  need  to  understand  the  latter  in 
terms  of  the  real  world.  In  the  first  case,  efforts  are  being  made  to  standardize 
statistical  elements  and  definitions  used  in  measuring  reliability  through  the  life 
cycle,  to  develop  a  single-thread  data  system  and  prescribe  more  realistic  test 
plans.  In  the  second  case,  the  production  and  test  world  does  not  simulate  the 
operational  world.  We  should  not  expect  it  to;  we  are  not  apt  to  spend  the 
amount  of  test  money  that  would  be  required  to  simulate  a  ten-year  life  cycle. 

As  a  consequence,  mature  reliability  can  only  be  measured  during  the  operational 


phase.  Hardware  characteristics  alone  do  not  determine  operational  results. 
Operational  performance  is  affected  by  such  things  as: 

(1)  Mission  profile 

(2)  Maintenance  operating  procedures  and  skills 

(3)  Operational  and  maintenance  concepts 

(4)  Support  and  test  equipment  availability  and  effectiveness 

(5)  Changes  in  operational  requirements  and  use  which  exceed  or  differ 
from  original  specifications 

(6)  Configuration  changes  after  initial  design 

(7)  Systems  interface  of  subsystems  and  equipment. 

It  is  not  likely  that  operation  of  military  systems /equipment  will  be  manda- 
torily  constrained  in  a  manner  necessary  to  achieve  precise  correlation  with  de¬ 
sign  performance.  Figure  14  [herein  Fig.  1-5]  provides  additional  insight  into 
the  relationship  between  test  and  operational  reliability.  Two  additional  factors 
are  shown:  The  K  factor  which  is  the  design  or  test  MTBF  divided  by  the 
operational  MTBF  and  the  %  achieved  which  is  the  latter  divided  by  the  test 
MTBF.  Both  of  these  factors  are  useful  in  estimating  one  of  the  values  when 
only  the  other  is  known.  While  general  inferences  can  be  drawn  from  these 
tables,  the  specific  cause  factors  for  variation  in  each  equipment  must  be  ex¬ 
amined  to  determine  appropriate  corrective  action  if  any,  and  K  factors  used  in 
prediction  of  operational  reliability  should  consider  the  particular  system /equip¬ 
ment  and  mission  being  proposed." 
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TEST  MIN  ACC 

K 

OPERATIONAL 

%  ACHIEVED 

A-7D  BOMB  NAVIGATION  SYS 

FORWARD  LOOKING  RADAR 

125 

6.25 

20 

0.167 

WEAPON  DELI  VERY. COMPUTER 

650 

6.84 

95 

0.146 

AIR  DATA  COMPUTER 

500 

2.85 

175 

0.350 

DOPPLER  RADAR 

250 

5.20 

48 

0.192 

HEAD  UP  DISPLAY 

350 

3.97 

88 

0.251 

INERTIAL  MEASUREMENT 

325 

4.22 

77 

0.237 

F-4  RADIO  NAVIGATION  SYS 

NAVIGATION  COMPUTER  SET 

■M 

(ASN46A)  (RF-4C) 

320 

8.00 

40 

NAVIGATION  COMPUTER  SET  (F-4E) 

320 

3.67 

87 

INERTIAL  NAVIGATION  SYS  (RF-4C) 

175 

4.60 

38 

I  ■ 

INERTIAL  NAVIGATION  SYS  (F-4E) 

180 

2.90 

62 

i 

LORAN  (RF-4C) 

50 

2.00 

25 

0.500 

INTEGRATED  ELECTRONIC  CENTRAL 

(ASQ-19A)  (F-4C) 

INTEGRATED  ELECTRONIC  CENTRAL 

27.5 

1.61 

17 

0.630 

(ASQ-19B)  (F^tE) 

27.5 

0.85 

32 

1.16 

RADAR  NAVIGATION  SYSTEM 

RADAR  ALTIMETER  IRF-4C) 

RADAR  MAPPING  SYSTEM  FORWARD 

400 

15.38 

26 

0.065 

LOOKING  RADAR  (RF-4C) 

90 

6.00 

15 

0.160 

SIDE  LOOKING  RADAR  (RF-4C) 

BOMBING  NAVIGATION  SYSTEM 

ATTITUDE  REFERENCE  BOMB 

56 

4.66 

12 

0.214 

COMPUTER  SET  (F-4D) 

173 

1.86 

93 

0.537 

COMPUTER  SYSTEM  (ASQ-91)  (F-4D) 

250 

1-Ot 

246 

0.984 

FIRE  CONTROL  SYSTEM 

RADAR  SET  (APQ-120)  (F-4E) 

9 

0.75 

12 

1.33 

TUNING  DRIVE  (F-4EI 

600* 

0.94 

632 

1.05 

LEAD  COMPUTER  SIGHT  (F-4E) 

300 

0.69 

430 

1.43 

•SPECIFICATIONS  WERE  NOT  AVAILABLE;  THEREFORE,  AIR  FORCE  OFFICIALS  ESTIMATED  THE 

MINIMUM  ACCEPTABLE  FIGURE. 

SYSTEM 

ARN-96  TACAN 

350 

3.50 

100 

0.285 

ARN-65  TACAN 

150 

1.76 

85 

0.567 

ARN-91  TACAN 

700 

2.33 

300 

0.429 

ARN-92  LORAN 

70 

1.16 

60 

0.857 

MA-I  IRAM  COMPUTER 

600 

7.89 

76 

0.127 

APQ-122  WX  RADAR 

350 

2.30 

152 

0.434 

B-58  SEARCH  RADAR 

60 

4.00 

15 

0.250 

WILCOX  807  RADIO 

600 

1.42 

420 

0.700 

ARC  109  UP  F  RADIO 

450 

3.14 

143 

0.318 

ALQ  87  ECM  POD 

57 

0.38 

150 

2.632 

F-106  MMST 

500 

33.33 

15 

0.030 

MEAN  0.46372:6  OUT  OF  13  <  50%. 

0719-059W  Figure  14.  Comparison  of  Operational  Reliability  vs  Minimum  Test  Demonstration. 

Fig.  1-5  Reprint  from  AFLCP  800-3,  "Logistic  Performance  Factors  in  Integrated  Logistic  Support" 
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2.  DESIGN  GUIDELINES  AND  PROCEDURES  -  CONCEPTUAL  PHASE 


During  this  phase ,  the  avionic  or  ground  electronic  system  performance 
parameters  are  defined  based  on  the  prime  system  mission  and  operational  per¬ 
formance  requirements.  The  system  engineering  process  depicted  in  Figure  2-1 
is  as  specified  in  AFLCP  800-3  and  MIL-STD-499. 

Top  and  first  level  function  and  sub -function  flow  diagrams  are  prepared 
reflecting  the  results  of  a  system  operational  analysis.  Each  function  is  allo¬ 
cated  a  set  of  performance  and  design  requirements  per  Requirements  Allocation 
Sheets  (RASs).  Time  requirements,  which  are  prerequisites  for  functions  af¬ 
fecting  mission  success,  safety,  and  availability  are  derived.  These  mission 
requirements  and  constraints,  when  developed  in  sufficient  detail,  provide  the 
necessary  parameters  for  derivation  of  prime  system  hardware  and  software  per¬ 
formance  requirements,  maintenance  concept,  and  test  subsystem  performance 
requirements . 

2.1  SELECTION  OF  THE  MAINTENANCE  CONCEPT 

The  system  analyst's  overriding  objective  is  to  optimize  system  cost  effec¬ 
tiveness  .  He  is  faced  with  the  problem  of  minimizing  LCC  while  maximizing  the 
Performance  (P),  Availability  (A),  Reliability  (R),  and  Survivability  (S)  param¬ 
eters  in  Eq.  1  of  paragraph  1.6.4.  The  solution  of  this  equation  will  vary  sig¬ 
nificantly  between  aircraft  avionic  systems  and  ground  electronic  systems. 
Equally  significant  variations  in  its  solution  will  result  from  the  different  avi¬ 
onics  requirements  for  fighter,  attack,  cargo,  and  bomber  aircraft.  This  holds 
true  for  communications,  data  processing,  early  warning  radar,  and  satellite 
ground  onic  systems  as  well. 

Thus,  the  performance  time  requirements,  parameters,  and  constraints 
listed  below,  as  derived  for  each  unique  aircraft  or  ground  electronic  system, 
are  the  driving  factors  that  determine  the  Support  Concept  and  its  test  subsys¬ 
tem  performance  characteristics : 


•  Performance /Time  Parameters 

-  Mean  Down  Time  (MDTq) 

-  Operational  Availability  (Aq) 

-  Utilization  Rate  (operating  hours  or  duty  cycle  per  unit  time) 

-  Duty  Cycle  (uptime  and  downtime  limits  —  continuous,  regularly 
scheduled,  random) 

•  Overriding  Constraints  /Limitations 

-  System  characteristics 

-  Funding 

-  Personnel  quantity /skills 

-  Existing  equipment  and  facilities 

-  Logistic  support /supply 

-  Environment. 

The  Maintenance  Concept  basically  defines  criteria  governing  the  scope  and 
proposed  methods  of  test  and  repair  at  each  level  (O,  I,  and  D)  of  maintenance. 
It  attempts  to  satisfy  the  time  line  parameters  above ,  within  the  overriding  con¬ 
straints  and  limitations.  The  guidelines  and  procedures  for  test  subsystems  de¬ 
sign  that  follow  address  the  usual  prime  system,  supported  within  the  existing 
Air  Force  supply  system  by  existing  personnel  skills,  etc.  These  procedures 
can  be  readily  modified  to  account  for  any  exceptional  overriding  constraints  or 
limitations  imposed  due  to  a  unique  prime  system  or  support  concept. 

For  most  avionic  and  ground  electronic  systems ,  the  organizational  level 
support  concept  limits  the  maintenance  tasks  to  system  testing,  fault  detection, 
fault  isolation,  and  repair.  During  the  System  Conceptual  Design  Phase,  the 
prime  consideration  is  to  define  and  specify  a  cost  effective  test  subsystem  to 
perform  the  above  tasks  within  the  prime  system  operating  time  lines.  The 
specification  must  also  provide  sufficient  flexibility  and  latitude  to  permit  the 
system  and  subsystem  designers  to  optimize  the  detailed  hardware  and  software 
designs. 


The  procedure  for  test  subsystem  design,  and  its  complex  interrelationship 
with  the  prime  system  design,  is  presented  in  a  simplified  form  in  Fig.  2-2.  This 
is  an  iterative  process  which  is  not  shown  in  the  figure.  Progressively  more  de¬ 
tailed  trade-offs  are  performed  as  the  prime  system  and  test  subsystem's  func¬ 
tional  requirements  are  analyzed  with  increasing  detail.  Avoiding  the  redundan¬ 
cy  of  addressing  the  iterative  nature  of  this  optimization  procedure,  the  study 
will  provide  test  subsystem  design  tools  and  guidelines  for  its  accomplishment. 
The  prime  system  design  will  be  influenced  by  the  proper  selection  of: 

•  Test  Subsystem  Performance  Requirements  (Block  1  of  Fig.  2-2)  which 
include 

-  Effectiveness  and  Uncertainty  (ET  and  UT)  as  defined  below 

-  Allowable  Mean  Down  Time  (MDT  )  and  Mean  Corrective  Maintenance 

_  o 

Time  (M  .) 
ct 

•  Test  Subsystem  Life  Cycle  Cost  Target  (Block  3  of  Fig.  2-2). 

The  simplified  procedure  of  Fig.  2-2  will  be  addressed  in  a  logical  flow  as 
follows : 

•  Specify  test  subsystem  performance  requirements 

•  Select  alternate  test  subsystem  concepts 

•  Evaluate  LCC  impact  of  the  test  subsystem 

•  Evaluate  each  candidate  test  subsystem's  performance  and  LCC 

Having  exhausted  all  viable  concepts  the  optimum  test  subsystem  is  then 
selected  and  specified. 

2.2  TEST  SUBSYSTEM  PERFORMANCE  REQUIREMENTS  (ET  and  UT)  (STEP  1A) 

The  effectiveness  (E^)  of  PM/BIT,  external  test  equipment  or  any  combina¬ 
tion  of  the  two  is: 

E  _  the  total  No.  of  malfunctioning  LRUs  (1) 

T  the  total  No.  of  O-level  maintenance  actions  (2)  (Eq.  8) 

The  delta  or  difference  between  (1)  and  (2)  is  the  number  of  no  defect 
maintenance  actions /removals  that  occur  due  to  test  subsystem  lack  of  capability. 


Procedure  for  Test  Subsystem  Design  •  Concept  Phase 
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The  uncertainty  (UT)  of  the  test  subsystem  is  the  reciprocal  of  ET,  i.e. : 

the  total  No.  of  O-level  maintenance  actions  (2) 

T  the  total  No.  of  malfunctioning  LRUs  (1) 

The  AFR-66- 1/65- 110  maintenance  reporting  system  currently  provides: 

•  The  number  of  repair-in-place  or  adjustment  maintenance  actions 

•  The  number  of  remove  and  replace  actions  resulting  from  an  identified 
malfunction 

•  The  number  of  no-defect  removals  as  determined  in  the  I-level  shop. 

The  inaccuracy  of  the  AFR  66-1/65-110  reporting  system  is  inherent  in  the 
last  term  since  there  is  no  way  of  knowing  whether  the  no-defect  LRU  was  due 
to  a  technician  error,  a  pilot  or  crew  squawk  error,  a  test  subsystem  error,  or 
an  error  made  by  the  I-level  test  equipment.  The  inability  of  the  AFR  66-1/ 
65-110  system  to  report  no-defect  O-level  removals  and  their  cause,  can  and 
should  be  resolved  by  instituting  a  maintenance  action  tracking  and  analysis 
system  which  permits  detection  of  their  occurrence,  analysis  of  their  cause,  and 
corrective  action  to  be  taken .  For  purposes  of  this  study ,  it  is  assumed  that 
such  a  system  will  be  instituted  and  that  AFR  66-1/65-110  data  will  be  available 
to  record  no-defect  O-level  removals  due  to  test  subsystem  lack  of  capability. 

With  the  addition  of  these  data  both  ET  and  UT  can  be  calculated  during 
the  various  system  design  phases  and  then  measured  using  that  data.  The 
equations  are: 

C+R  R  ,+C+R 

ET  =  R  ,+C+R  811(1  UT  =  C+R  (Eqs.  10  and  11) 

nd  r  r 

where  E^  =  the  effectiveness  of  the  test  subsystem,  U^  =  the  uncertainty  of  the 
test  subsystem ,  C  =  the  number  of  repair-in-place  or  adjustments  required , 

Rr  =  the  number  of  remove  and  replace  actions  due  to  a  failure,  and  Rn(j  =  the 
number  of  O-level  no-defect  removals  due  to  test  subsystem  lack  of  capability. 

Thus,  the  number  of  no-defect  removals  determines  the  test  subsystem's 
effectiveness  and  uncertainty. 
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The  maximum  allowable  number  of  no-defect  removals  may  be  specified  as  a 
percentage  of  the  total  number  of  true  malfunctioning  LRUs: 

R 


%  R 


nd 


nd  C+R. 


(Bq.  12) 


where  the  terms  are  as  previously  defined.  This  percentage  then  may  be  fur¬ 
ther  subdivided  into  an  allowable  or  specified  percentage  for  each  of  the  test 
subsystem  attributes.  These  are: 

•  FA  =  %  no-defect  removals  due  to  False  Alarms 

•  BDE  =  %  no-defect  removals  due  to  BIT  Diagnostic  Errors 

•  UF  =  %  no-defect  removals  due  to  Undetected  Failures 

•  BA  =  %  no-defect  removals  due  to  BIT  Ambiguity 
Therefore : 

%  R  .  =  FA  +  BDE  +  UF  +  BA  (Eq.  13) 

nd 


where  the  above  terms  are  as  defined  in  paragraph  1.4.3.  In  the  discussions 
which  follow  it  will  be  shown  that  no-defect  removals  are  generally  caused  by 
these  four  test  subsystem  attributes.  Guidelines  for  establishing  allowable  no¬ 
defect  removal  rates  for  each  attribute  will  be  provided.  This  not  to  infer 
that  these  specific  parameters  must  be  achieved  and  demonstrated  for  each  se¬ 
lected  subsystem .  Rather ,  the  intent  is  to  provide  a  basis  for  specifying  the 
maximum  total  no-defect  removals  (%Rnd)  for  each  subsystem.  The  specifi¬ 
cation  and  demonstration  of  this  composite  parameter  will  provide  the  necessary 
flexibility  and  latitude  for  the  designer  to  optimize  the  test  subsystem.  Achieve¬ 
ment  of  the  required  composite  no-defect  removal  rate  should  be  demonstrated  at 
both  the  subsystem  and  system  level  to  a  high  degree  of  confidence  (2  to  3 
sigma) .  The  demonstration  should  be  made  on  the  prototype  test  and  evaluation 
unit  during  the  Full  Scale  Development  Phase  to  permit  hardware  and  software 
changes  or  modifications  prior  to  the  Production  Phase.  To  further  assure  the 
quality  of  the  production  test  subsystem ,  formal  qualification  testing  should  be 
required  using  initial  preproduction  systems.  These  engineering  tests  are  to 
resolve  reported  errors  and  make  the  necessary  design  changes. 


2.2.1  PM /BIT  False  Alarms  (FA) 

A  false  alarm  occurs  when  PM /BIT  or  external  test  equipment  identifies  an 
LRU  as  faulty  when  in  fact  there  is  no  malfunction.  Units  removed  due  to  false 
alarms  are  processed  from  the  O-level  to  the  I-level  and/or  D-level  shop  and  are 
indistinguishable  from  other  no-defect  removals.  Therefore,  false  alarms  must 
(for  the  present)  be  considered  an  unidentifiable  subset  of  no-defect  removals. 

A  false  alarm  may  be  caused  by  the  improper  setting  of  PM /BIT  or  external 
test  equipment  tolerances.  An  apparent  false  alarm  may  be  caused  by  intermit- 
tents  and  transients  which  temporarily  degrade  the  equipment's  performance. 

The  technology  exists  to  eliminate  or  reduce  false  alarms  to  an  acceptable  level, 
especially  if  they  are  investigated  early  in  the  equipment  design  and  test  phase. 
This  is  recommended  because  the  cost  of  making  changes  to  production  Hardware 
and  software  to  eliminate  false  alarms  may  be  prohibitive. 

The  apparent  number  of  false  alarms  is  significantly  inflated  by  the  follow¬ 
ing  causes  which  may  or  may  not  be  true  test  subsystem  false  alarms: 

•  A  transient  or  intermittent  which  temporarily  degrades  operational  per¬ 
formance  and  which  cannot  be  duplicated  in  the  system  test  mode  (this 
is  a  true  fault) 

•  A  malfunction  within  the  PM /BIT  or  external  test  equipment  (this  is  a 
true  fault) 

•  The  inability  of  the  I-level  AGE  or  ATE  test  programs  to  detect  certain 
modes  of  failure  (these  are  not  false  alarms) 

•  Crew  or  operator  squawks  which  are  in  error  (these  are  squawk  errors). 

The  symptom  vs  problem  truth  table  of  Fig.  2-3  illustrates  the  subtlety  of 
the  last  two  errors.  If  the  I-level  test  equipment  erroneously  identifies  a  mal¬ 
functioning  unit  as  a  no-defect  removal,  as  illustrated  in  lines  2  and  4  of  the 
figure,  it  may  circulate  in  the  supply  system  continuously  building  up  the  num¬ 
ber  of  no-defect  removals  until  the  problem  is  identified.  These  are  often  re¬ 
ferred  to  as  "loser"  boxes. 
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BIT 
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NO  GO 

NO  GO 

LRU 
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NO  GO 

NO  GO 

LRU 

MALFUNCTION 

GO  (FALSE) 

GO 

NO  GO 

BIT 

FALSE  ALARM 

GO  (TRUE) 

GO 

NO  GO 
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FALSE  ALARM 

GO  (FALSE) 
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ATE/AGE 

ERROR 
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ATE/AG! 

ERROR 


Fig.  2-3  Falsa  Alarms?  Symptoms  vs  Actual  Problem* 


Our  study  concludes  that  false  alarms,  whether  apparent  or  actual,  gen¬ 
erally  indicate  actual  problems  that  can  and  should  be  corrected.  This  discussion 
is  further  amplified  in  Appendix  D  -  Interrelationships  Between  Intermittents  and 
BIT  False  Alarms,  and  Some  BIT  Design  Guidelines  Relating  to  These  Issues. 

2.2.2  PM /BIT  Diagnostic  Errors  (BDE) 


Given  that  a  malfunction  exists  within  a  system,  a  PM /BIT  diagnostic  error 
has  occurred  when  the  PM /BIT  identifies  a  good  LRU  as  faulty  due  to  that  sys¬ 
tem  malfunction.  The  symptoms  of  the  error  as  observed  by  an  O-level  main¬ 
tenance  technician  may  be  identical  to  a  false  alarm  when  the  true  faulty  LRU  is 
undetected  by  PM /BIT.  The  PM /BIT  diagnostic  error  is  a  significant  cause  of 
no-defect  removals  since  it  reflects  the  inability  of  the  test  subsystem  designer 
to  accurately  predict  all  failure  modes  and  to  perfectly  evaluate  these  using 
sensors  and  software  logic.  As  with  false  alarms  we  oonclude  that  the  technology 
exists  to  eliminate  the  test  subsystem  design  omissions  and/or  errors  through 
the  process  of  early  test  and  correction  both  at  the  subsystem  and  integrated 
system  level.  We  therefore  conclude  that  the  specified  maximum  allowable  PM/ 

BIT  diagnostic  error  rate  can  be  held  to  a  small  and  acceptable  percent  of  the 
actual  failure  rate. 


2.2.3  PM/BIT  Undetected  Failures  (UF) 


An  undetected  failure  occurs  when  the  operator  or  maintenance  technician 
observes  the  symptoms  of  a  malfunction  and  is  unable  to  detect  or  to  isolate  to 
the  malfunctioning  LRU  using  his  test  subsystem.  Undetected  failures  manifest 
the  inability  of  the  test  subsystem  designer  to  predetermine  all  failure  modes  so 
that  he  can  incorporate  the  logic  necessary  to  detect  and  isolate  them. 

Given  that  a  malfunction  has  occurred  which  is  not  detected  by  PM /BIT, 
but  is  observed  by  the  operator,  the  maintenance  approach  in  most  cases  will  be 
to  replace  an  indeterminate  number  of  suspect  or  likely-to-fail  LRUs  until  a  fix 
is  achieved.  Thus  undetected  failures  are  also  a  subset  of  no-defect  removals 
since  the  result  is  an  increased  flow  of  no-defect  LRUs  into  the  1  or  D-level 
shops.  Without  the  recommended  tracking  and  analysis  system,  undetected 
failures  are  confused  with  squawk  errors,  BIT  tolerance  errors,  and  I-level 
ATE/AGE  tolerance  errors  as  shown  in  Fig.  2-4. 
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Similiar  to  false  alarms ,  undetected  failures  can  be  reduced  to  a  tolerable 
minimum  through  early  test  and  evaluation  during  the  Full  Scale  Development 
Phase. 

2.2.4  PM /BIT  Ambiguity  (BA) 

The  ambiguity  of  a  test  subsystem  is  a  measure  of  its  capability  to  detect 
and  fault  isolate  a  failure  to  one  or  more  LRUs.  A  non- ambiguous  test  subsys¬ 
tem  would  isolate  all  detected  failures  to  a  single  faulty  LRU.  This  objective  is 
seldom,  if  ever,  achieved  in  state-of-the-art  designs.  The  reasons  are  usually 
design  cost,  hardware  and  software  complexity,  added  volume,  weight,  and  un¬ 
reliability  of  the  test  subsystem.  During  the  Conceptual  Phase,  these  details  of 
the  system  design  are  seldom  known  and  are  almost  impossible  to  estimate  with 
any  degree  of  certainty.  Therefore,  to  determine  the  allowable  BIT  or  test  sub¬ 
system  ambiguity  (BA),  the  test  subsystem  designer  must  weigh  the  penalties 
vs  the  benefits  of  alternate  test  subsystem  concepts  as  reflected  in  historical 
data  and  experience. 

2.2.5  Specification  of  E^,  Based  on  Historical  Data 

Test  subsystem  effectiveness  (ET),  as  stated  previously,  is  determined  by 
the  no-defect  removal  rate  (%  Rnd).  The  historical  data  necessary  to  statisti¬ 
cally  quantify  or  specify  the  elements  of  %  Rnd  (FA,  BDE,  UF,  BA)  is  currently 
unavailable.  However,  estimates  of  achievable  ET  and  %  Rnd  for  test  subsystems 
with  varying  degrees  of  automation  and/or  external  test  equipment  can  be  based 
on  the  study  literature  survey  and  Grumman  experience.  These  data  are  re¬ 
flected  in  Fig.  2-5. 

The  broad  range  of  values  shown  is  due  to  large  variations  in  avionic  and 
ground  electronic  system  characteristics  and  complexity.  The  key  points  il¬ 
lustrated  are: 

•  Mean  corrective  maintenance  time  (Mct)  is  the  major  determinant  in 
selecting  the  candidate  test  subsystem 

•  The  prime  system's  characteristics  are  a  key  determinant  in  selecting 
the  optimum  PM /BIT  effectiveness  goal. 


I.  2-5 


Since  M£t  is  determined  by  the  prime  system's  operational  analysis,  it  is  a 
test  subsystem  requirement  which  cannot  be  traded  off.  The  question  then 
arises,  "What  is  the  impact  of  the  test  subsystem's  performance  (E^,)  on  the 
prime  system's  availability  and  mean  down  time?"  Also,  "How  does  the  reliability 
of  the  test  subsystem  affect  the  prime  system's  availability?"  These  questions 
will  be  addressed  in  the  paragraphs  that  follow. 

2.3  TEST  SUBSYSTEM  PERFORMANCE  REQUIREMENTS  (MDTq  &  M^) 

(STEP  IB) 

During  conceptual  design  trade-offs  between  reliability,  maintainability, 
effectiveness,  and  cost,  the  designer  strives  to  achieve  high  operational  readi¬ 
ness  and/or  mission  reliability.  The  .  •  .ameters  which  have  the  greatest  impact 
on  operational  readiness  and  availability  are  MDTq  and  MTBFq.  Mean  down  time 
includes  unscheduled  and  scheduled  maintenance  time  (NORM),  logistic  down 
time  (NORS),  and  awaiting  maintenance  time  (AWM)  and  other  administrative  or 
handling  delay  time.  All  of  these  are,  for  the  most  part,  determined  by  the  op¬ 
erating,  maintenance,  and  logistic  support  concepts  with  the  exception  of  NORM 
which  is  strongly  influenced  by  the  maintenance  characteristics  (Mct)  of  the 
equipment. 

A  theoretical,  but  practical  definition  of  availability  which  can  be  used  for 
relative  evaluation  purposes  when  comparing  existing  systems,  is  Eq.  4  of 
paragraph  1.6.4: 


MTBF0 

Ao  =  MTBF  +  MDT 
o  o 


(Eq.  14) 


MTBF 


where  MTBF  =  O-level  mean  time  between  failure  based  on  true  maintenance 
o 

actions,  and  MDT^  =  mean  down  time,  including  active  repair  time,  administrative 
time,  and  logistic  delay  time.  Mean  down  time  as  was  expressed  in  Eq.  5  is: 

MDT  =  M\  +  M,  +  M  +Wt 
o  ct  1  a  pt 

where  M^  =  mean  corrective  maintenance  time,  W  =  mean  logistic  delay  time, 

M  =  mean  administrative  delay  time,  and  M*  =  mean  preventive  (scheduled) 

pt 

maintenance  time  plus  modifications. 


The  test  subsystem's  performance,  while  not  the  controlling  factor  (since 
logistics  and  administrative  delay  times  are  frequently  major  items)  may  have  a 
significant  influence  on  each  of  the  above  terms,  with  the  exception  of  Mpt . 

Addition  of  BIT  will  increase  the  system  complexity  and  hence  the  failure 
rate  (MTBFq)  to  the  degree  that  components  and/or  software  are  added  to  ac¬ 
complish  the  BIT  function.  A  figure  of  merit  is  used  to  express  the  change  in 
failure  rate  due  to  BIT: 


(Eq.  15) 


R  -  ^system 
BIT  ^system  +  *  BIT 

It  is  generally  concluded  in  the  study  literature  that  the  failure  rate  of 
BIT  circuitry  and/or  software  should  not  exceed  10%  of  the  system's  failure  rate, 
i.e.:  =^0.9  (note  that  only  BIT  circuitry  and  software  are  considered, 

not  PM /BIT,  since  performance  monitoring  is  a  system  function). 

The  uncertainty  (U^,)  of  the  test  subsystem,  reflected  in  no-defect  re¬ 
movals,  will  drive  M^,  M^,  and  Ma  as  some  function  of  UT  depending  on  the 
support,  maintenance,  and  logistic  concepts.  For  the  purpose  of  comparing 
different  system  concepts ,  use  of  the  following  linear  relationship  will  provide 
sufficient  accuracy: 


MDT 


(Mct+M1+Ma)  f(UT)  +Mpt 


(Eq.  16) 


which  yields: 


MDT 


(Mct+M1+Ma)  (UT)  +Mpt 


(Eq.  17) 


The  scheduled  maintenance  (Mpt)  for  both  avionics  and  ground  electronics 
is  negligibly  small,  especially  when  comparing  prime  systems. 

Applying  the  above  relationships  to  Eq.  14  for  existing  equipment,  the  im¬ 
pact  of  adding  BIT  would  yield: 


Ao  = 


1  + 


(Mct+ V^a)  UT 


(Eq.  18) 
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MTBFo  x  RBIT 


1 

MDT 

1  + - 2x  F 

MTBF 


(Eq.  19) 


where  F  equals  the  figure  of  merit  for  the  test  subsystem  and  is  defined  as: 

UT 

F  =  r-1-  (Eq.  20) 

nBIT 

The  definition  applies  equally  to  prime  systems  and  subsystems.  It  is  not 
applicable  to  systems  in  standby,  alert,  or  in  a  degraded  mode  of  operation. 
Figure  2-6,  a  log  plot  of  this  equation,  shows  that  both  MDTq  and  MTBFq  are 
sensitive  parameters  in  the  calculation  of  operational  availability.  It  also  shows 
the  impact  of  test  subsystem  performance  on  the  availability  characteristics  of  a 
system. 

A  similar  relationship  exists  for  Inherent  Availability  (A^)  as  impacted  by 
the  test  subsystem  performance: 


(Eq.  21) 


1  + — —  x  F 
MTBF 


The  curves  of  Figure  2-6  provide  a  theoretical  measure  of  the  sensitivity  of 
the  prime  system's  availability  to  the  test  subsystem's  performance  and  reliabili¬ 
ty.  Several  conclusions  and  guidelines  are: 

For  MC[/MTBF  ratios  <<0.01,  the  prime  system  availability  is  relatively  insensitive  to  the 
test  subsystem  performance.  Therefore,  in  this  region  other  parameters  such  as  cost,  weight,  size, 
etc.  become  dominant  factors  in  specifying  the  test  subsystem 's  performance. 

For  MC[/MTBF  >  0.01,  the  prime  system  availability  becomes  increasingly  sensitive  to  the 
ratio  of  Uj/Rgjj.  Equally  important,  as  the  test  subsystem  designer  attempts  to  improve  the  ef¬ 
fectiveness  of  BIT,  the  greater  the  likelihood  that  the  BIT  reliability  penalty  (Fgjj')  w///  offset  the 
improvement.  This  suggests  that  the  factor  F  might  be  specified,  where  F  <  approximately  1.5, 
thus  providing  the  test  subsystem  designer  the  opportunity  to  optimize  the  ratio  of  Vjto 

rBIT. 


2.4  SELECTION  OF  ALTERNATE  TEST  SUBSYSTEM  CONCEPTS  (STEP  2) 


The  system  mission  and  operations  analysis  must  quantify  and  optimize 
performance  based  on  the  critical  operational  requirements ,  use  conditions ,  and 
the  maintenance  concept.  The  quantitative  requirements  leading  to  the  mainte-' 
nance  concept  are: 

•  Operational  Readiness  Requirements  -  this  includes  operational  ready 
rate,  turn-around  time,  steady  state  availability,  and  any  mission  dic¬ 
tated  reaction  time 

•  Deployment  and  Support  Plans  -  this  includes  system  or  equipment  in¬ 
stallation  configuration  and,  as  applicable,  the  systems  or  vehicles  into 
which  the  new  system  is  to  be  integrated.  Also  included  are  maintenance 
and  support  provisions  dictated  by  the  proposed  deployment  and  by  the 
existing  support  system 

•  Use  Conditions  and  Limitations  -  such  as  personnel  resource  constraints 
in  terms  of  skills,  skill  levels,  and  quantities,  maintenance  manhours  per 
operating  hour,  packaging  and  dimensional  requirements  and  like  re¬ 
strictions  . 

The  organizational  level  test  and  repair  concepts  are  therefore  constrained 
to  achieve  the  above  quantitative  requirements  within  the  planned  logistic  sup¬ 
port  environment.  Due  to  the  wide  variation  of  such  requirements,  there  is  no 
single  global  solution  to  optimizing  a  test  subsystem.  Rather,  the  solution  will 
be  unique  to  each  prime  system. 

In  the  following  paragraphs,  general  guidelines,  criteria  and  procedures 
for  selecting  the  candidate  test  subsystem  concepts  will  be  given  for  both  avionic 
systems  and  ground  electronic  systems.  Operational  or  mission  reliability  is  the 
dominant  parameter.  Mission  reliability  of  the  equipment  determines  the  O-level 
workload,  while  the  system  allowable  down  time  (MDTq)  or  turn-around  time 
dictates  the  elapsed  time  within  which  the  workload  must  be  accomplished. 

2.4.1  Test  Subsystem  Selection  For  Avionic  Systems 

The  interrelationship  between  the  mean  down  time  (MDTq)  and  the  aircraft 
operational  readiness  rate  (which  is  driven  by  the  turn-around  time)  is  complex 
as  illustrated  in  a  simplified  form  in  Fig.  2-7. 
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Fig.  2-7  Operational  Mean  Downtime 


The  aircraft  system  designer  incorporates  maintenance  features  to  minimize 
both  scheduled  and  unscheduled  maintenance  and  turn-around  time  (TAT)  for 
each  maintenance  activity  shown  in  the  figure.  As  stated  earlier  in  Subsection 
2.3,  the  operational  mean  down  time  (MDTq)  ,  calculated  as: 

MDT  k(M  .  +  M,  +  M  )  f(U„)  +  M  .  (See  Eq.  16) 

o  ct  l  a  i  pt 

is  illustrative  of  the  avionic  system  designer's  problems.  Assume  that  the  re¬ 
quired  TAT  is  30  minutes  or  less  (typical  of  current  aircraft  designs) ,  and  that 
the  mean  logistic  and  administrative  delay  times  (M.  +  M  )  are  in  the  order  of  10 
to  20  minutes,  as  dictated  by  the  operation,  deployment,  and  logistic  support 
concepts.  These  delays  will  be  further  amplified  by  no-defect  removals  as  a 
function  of  the  test  subsystem's  uncertainly  (U^,).  The  degree  of  these  delays 
is  a  unique  characteristic  of  each  prime  system  and  is  sin  output  of  the  system's 
operational  and  mission  models. 


39 
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The  task  timelines  for  M  of  Fig.  2-8  show  that  all  elements  of  a  corrective 

cli 

maintenance  action  except  "gain  access,"  "repair  or  replace,"  and  "reassemble" 
are  reduced  in  time  by  PM /BIT.  The  amount  of  reduction,  over  that  of  manual 
fault  isolation  using  external  test  equipment  is  highly  dependent  on  the  equip¬ 
ment  complexity,  characteristics,  and  other  factors.  The  data  presented  in  Fig. 
2-9  are  derived  from  NAVSHIPS  94324  and  based  on  experience  with  shipboard 
and  shorebased  electronic  equipment.  These  data  illustrate  the  reduction  in 
M  which  can  be  obtained  with  fully  automatic  and  semi-automatic  test  subsys¬ 
tems. 

Returning  to  the  example,  in  which  the  required  aircraft  TAT  is  in  the 
order  of  30  minutes  and  the  mean  logistics  and  administrative  delay  time  is  in  the 
order  of  10  to  20  minutes,  the  achieveable  M  ^  of  Fig.  2-9  indicates  a  necessity 
for  rapid,  fully  automatic  PM /BIT.  Further,  this  necessity  coupled  with  the 
MTBF  (for  avionics  systems  in  the  order  of  1  to  10  hours),  dictates  a  need  to 
specify  the  minimum  achievable  test  subsystem  uncertainty  (UT) . 


EQUIPMENT  MAINTENANCE  CONCEPT 

FAULT  LOCATION  METHOD 

REPAIR  BY 

MODULE  REPLACEMENT 

REPAIR  IN  PLACE  BY 
PARTS  REPLACEMENT 

MANUAL  (NO  ATE)* 

1.0  HR 

2.5  HR 

SEMI-AUTOMATIC** 

0.5  HR 

1.5  HR 

FULLY  AUTOMATIC*** 

0.2  HR 

N/A 

•Manual  fault  location  is  accomplished  using  external  test  equipment  and  built-in  test  points. 


••Semi-automatic  fault  location  identifies  the  approximate  location  of  fault.  Isolation  to  the 
particular  module  or  part  to  be  replaced  is  then  accomplished  manually,  using  external  test 
equipment. 

•••Fully  automatic  fault  location  identifies  the  exact  unit  or  part  to  be  replaced.  No  external 
test  equipment  is  required. 

Note:  Data  presented  are  derived  from  NAVSHIPS  94324,  based  on  experience  with  shipboard 
&  shorebased  electronic  equipment  &  should  be  used  for  estimating  maintainability 
feasibility  of  systems  &  equipments  which  are  predominantly  electronic. 
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Therefore,  fully  automated  PM  /BIT  is  recommended  for  avionic  O-level  support,  except  for 
non-critical  highly  reliable  functions  which,  for  reasons  of  weight,  volume,  or  infrequent  use  are 
not  reasonable  candidates  for  PM/BIT. 

For  these  exceptions  an  allocated  M_t  and  the  acquisition  cost  for  each  item  of 

i 

external  test  equipment  should  be  established  based  on  historical  data  and  speci¬ 
fied  as  a  test  subsystem  requirement. 

As  will  be  discussed  in  Subsection  2.5,  specifying  these  requirements  af¬ 
fects  many  elements  of  the  LCC.  Acquisition  costs  are  increased,  OkS  costs  are 
decreased,  and  improved  effectiveness  is  achieved  in  accordance  with  the  rela¬ 
tionships  and  estimating  procedures  defined  in  this  Subsection.  The  evaluation 
of  LCC,  however,  is  made  to  establish  and  trade-off  the  total  cost  of  PM/BIT  im¬ 
plementations.  It  is  not  made  to  trade-off  alternatives,  such  as  external  support 
equipment,  since  there  is  no  viable  alternative  to  BIT  (within  the  current  state- 
of-the-art)  for  the  test  and  fault  isolation  of  avionic  equipment  at  the  O-level. 

2.4.2  Test  Subsystem  Selection  for  Ground  Electronic  Systems 

The  test  subsystem  optimization  processes  for  ground  electronic  systems 
and  avionic  systems  are  similar  in  most  respects.  The  criteria  for  selecting  the 
test  subsystem  is  different  due  to  the  inherent  differences  in  mission  and  opera¬ 
tional  requirements.  The  relative  lack  of  weight,  volume  and  power  constraints 
allows  the  ground  system  designer  much  broader  latitude  in  selecting  both  sys¬ 
tem  configuration  and  the  test  subsystem  concept. 

2. 4. 2.1  Ground  System  with  Critical  Operational  Demand  -  Similar  to  the  avionic 
system  design  process,  functional  flow  diagrams,  requirements  analysis  sheets, 
and  time  lines  are  prepared  as  the  first  step.  The  ground  electronics  designer 
is  faced  with  the  problem  of  minimizing  LCC  while  maximizing  Performance  (P) , 
Availability  (A),  Reliability  (R),  and  also  Survivability  (S),  where  applicable. 
However,  unlike  the  avionics  designer,  the  ground  electronics  system  designer 
can  incorporate  single  or  multiple  redundancy  to  achieve  ti.»-  required  mission 
reliability  and  availability. 


! 

! 

i 

As  in  avionic  systems,  the  required  operational  availability,  the  opera¬ 
tional  demand  period,  and  the  allowable  mean  down  time  vary  with  the  mission, 
the  operational  concept,  and  the  support  concept.  There  is,  however,  a  degree 
of  commonality  of  operational  demand  and  allowable  down  time,  even  among  such 
diverse  systems  as  the  AN/FPS-27  air-defense  search  radar,  the  AN/GPA-67 
frequency-diversion  data-link  equipment,  the  AN/TRC-66  Tropo-scatter  radio 
set ,  etc. 

A  selected  group  of  52  Air  Force  ground  equipments  and  subsystems  were 
classified  according  to  operational  demand  and  criticality.  These  are  summarized 
in  Fig.  2-10  to  indicate  the  spectrum  of  existing  or  anticipated  operating  profiles 
for  Air  Force  ground  equipments.  The  two  non- critical /random  use  equipments 
are  a  public  address  system  and  a  manual  meteorological  set ,  both  of  which  are 
exceptions,  rather  than  the  rule. 
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Fig.  2-10  Survey  of  Ground  Equipment  Operetional  Demand  vs  Criticality 


The  equipment  whose  operational  demand  is  required,  i.e.,  "Continuous  24 
Hours  per  Day"  and  "Random  Use"  account  for  67%  of  the  equipment  surveyed. 
These  operational  requirements  are  usually  achieved  by  partial  or  total  redundancy 
with  on-line  maintenance.  For  these  systems,  the  operational  maintenance  concept 


usually  requires  that  O-level  maintenance  technicians  be  available  at  all  times. 
Upon  indication  of  a  failure,  the  faulty  unit(s)  are  switched  off-line,  fault  iso¬ 
lated,  repaired,  and  placed  on  standby. 

The  test  subsystem  concept  selection  guidelines  for  ground  electronic  sys¬ 
tems  whose  operation  is  essential  and  continuous,  or  essential  and  random,  are; 

Evaluate  the  sensitivity  of  the  prime  system's  Availability  (A)  parameter  to  the  test  subsystem 
performance  as  detailed  in  subsection  2.3  and  Fig.  2-6. 

For  ratios  of  Mct/MTBF  in  the  order  of  0. 01  and  greater,  the  prime  system ’s  availability  is 
seriously  influenced  by  the  test  subsystem  selected.  This,  in  turn,  should  influence  the  selection  of 
a  fully  automatic  PM /BIT  test  subsystem. 

For  ratios  of  MC(/MTBF  in  the  order  of  0. 01  and  smaller,  the  test  subsystem  can  be  selected 
from  alternatives  1  through  4  of  Fig.  2-5. 

The  performance  of  each  candidate  is  then  evaluated  by  selecting  the  re¬ 
quired  Et  and  BIT  reliability  figure  of  merit  With  these  parameters, 

the  theoretical  Availability  (Ap  achieved  by  each  candidate  can  be  calculated 
as  described  in  subsection  2.3. 

2. 4. 2. 2  Ground  Systems  with  Non-Critical  Operational  Demand  -  This  class  of 
ground  electronic  systems  is  characterized  by  a  less  stringent  down  time  (typi¬ 
cally  1  or  more  hours)  for  maintenance  during  the  operational  demand  period. 

The  lack  of  criticality,  however,  does  not  imply  that  there  is  no  critical  main¬ 
tenance  requirement.  For  this  class  of  equipment,  the  critical  maintenance  re¬ 
quirement  may  be  shifted  from  M  ^  to  mean  down  time  (MDTq)  ,  which  then 
would  place  the  emphasis  on  logistics  delay  (M.)  and  administrative  delay  (B  ). 

i  a 

On  the  other  hand ,  the  critical  maintenance  requirement  may  be  the  maxi¬ 
mum  allowable  time  to  repair  (MmaXct> »  which  will  then  be  converted  per  MIL- 
STD-471  to  the  required  Mct.  In  either  case,  the  problem  and  the  procedure  for 
selecting  the  test  subsystem  is  similar  to  that  outlined  in  paragraph  2.  4. 2.1. 

For  ground  electronic  systems  with  non-critical  operational  demand  the  ratio 
of  M^/MTBF  will  generally  be  in  the  order  of  0.1  and  smaller  and,  therefore, 
the  test  subsystem  can  be  selected  from  alternatives  1  through  5  of  Fig.  2-5. 

For  these  non-critical  demand  systems,  external  test  equipment  or  PM /BIT  with 
varying  degrees  of  external  test  equipment  should  be  considered.  In  specifying 


new  or  existing  external  test  equipment,  the  equipment  designer  should  consider 
the  performance  of  the  external  test  equipment,  vs  PM /BIT  and  also  the  LCC 
impact  of  external  test  equipment  vs  PM  /BIT. 

2. 4. 2. 3  External  Test  Equipment  vs  PM/BIT  Evaluation  -  The  objective  of  eval¬ 
uating  test  subsystem  candidates  during  the  Conceptual  Phase  is  to  select  the 
generic  type  of  test  subsystem  and  its  performance  requirements  to  be  imposed 
during  the  System  Design  Phase ,  and  also  to  estimate  its  LCC  costs .  It  is 
entirely  conceivable  that  external  test  equipment  or  some  combination  of  BIT  and 
external  test  equipment  may  achieve  comparable  test  effectiveness ,  especially 
if  the  prime  system  is  functionally  simple.  For  systems  of  this  nature,  test  sub¬ 
system  acquisition  costs  may  prove  to  be  the  determining  factor. 

The  acquisition  costs  of  both  PM /BIT  and  external  test  equipment  are  ex¬ 
tremely  sensitive  to  the  number  of  systems  per  site  and  other  factors  as  shown 
in  Fig.  2-11.  The  major  points  illustrated  by  this  hypothetical  trade-off  are: 

(1)  PM/BIT  -  Production  costs  include  the  initial  software  cost  plus  the 
incremental  BIT  hardware  costs.  Performance  Monitoring  software  and 
hardware  costs  should  be  excluded. 

External  Test  Equipment  -  O-level  test  equipment  requirements  should 
be  calculated  based  on  the  expected  workload  multiplied  by  a  factor 
to  account  for  queuing  of  the  repairables  and  the  expected  availability 
of  the  test  equipment. 

(2)  PM /BIT  -  The  maintenance  man-hours  per  operating  hour  cannot  be 
reduced  below  the  minimum  maintenance  manning  level.  The  minimum 
maintenance  manning  level  is  defined  as  the  minimum  number  of  per¬ 
sonnel  of  each  skill  level  required  (per  shift)  to  perform  0  level  main¬ 
tenance  for  the  number  of  systems  per  .‘\te. 

External  Test  Equipment  -  The  maintenance  per  opeiating  hour  is  as 
defined  for  PM /BIT  above  with  the  exception  that  the  expected  main¬ 
tenance  workload  and  skill  requirements  will  be  greater  due  to  the 
greater  M  and  reduced  ET- 
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(3)  PM /BIT  vs  External  Test  Equipment  -  The  intent  of  Fig.  2-11  is  to 
provide  the  basic  approach  and  procedures  for  evaluating  the  cost 
impact  of  PM /BIT  vs  External  Test  Equipment.  The  details  of  Life 
Cycle  Cost  Analysis  are  provided  in  subsection  2.5 

2.5  TEST  SUBSYSTEM  LIFE  CYCLE  COST  (STEP  3) 

To  optimize  the  test  subsystem  design,  the  relative  worth  of  each  alternate 
test  concept  must  be  established.  Life  cycle  costing  techniques,  models,  and 
cost  data  available  from  industry  and  DoD  permit,  at  best  rough  order  of  magni¬ 
tude  estimates.  These  estimates  are  of  sufficient  validity  to  permit  trade-offs  and 
to  provide  a  "not-to-exceed"  design-to-cost  (DTC)  target. 

The  guidelines  and  procedures  of  the  following  paragraphs  utilize  historical 
factors,  percentages,  and  cost  estimating  relationships  that  will  result  in  a  valid, 
realistic  cost  target  rather  than  an  absolutely  accurate  cost  estimate.  Further 
refinement  and  improved  accuracy  of  the  LCC  will  be  achieved  during  the  System 
and  Subsystem  Design  Phases. 

2.5.1  Test  Subsystem  RDT&E  Costs 

For  most  systems  this  term  will  be  zero.  However,  in  certain  cases  where 
the  implementation  of  a  new  test  concept,  sensor,  or  measurement  technique  re¬ 
quires  research,  development,  test,  or  evaluation,  costs  will  be  estimated  for 
these  efforts.  Each  estimate  is  unique  and  must  be  a  "grass  roots"  engineering 
estimate  based  on  experience  and/or  historical  cost  data.  Estimates  must  include 
costs  to  develop  both  new  advanced  state-of-the-art  hardware  as  well  as  any  re¬ 
quired  software.  On  the  other  hand,  the  cost  of  applying  the  new  hardware/ 
software  in  a  deliverable  system  design  would  be  acquisition  costs. 

2.5.2  't'est  Subsystem  Acquisition  Costs 

Acquisition  costs  are  all  program  costs  beyond  the  RDT&E  phase  required  to 
introduce  into  operational  use  a  new  capability.  They  include  all  Procurement 
Appropriation  and  Military  Construction  Appropriation  costs  except  RDT&E, 
Military  Personnel,  and  Operation  and  Maintenance  Appropriation  costs.  Acquisi¬ 
tion  costs  are  divided  into  two  major  cost  elements :  the  weapon  system  produc¬ 
tion  costs;  and  initial  support  costs.  These,  in  turn,  are  sub-divided  into  the 
following: 
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Aircraft  Production  Costs 


Ground  Electronic  System 
Production  Costs 


•  Vehicle  (Airframe)  •  Facilities 

•  Avionics  •  Electro-Mechanical /Electro- 

•  Power  Plant(s).  Optical  equipment 

•  Electronic  equipment . 

Initial  Support  Costs  (for  both  aircraft  or  ground  electronic  systems) 

•  Spares 

•  Support  equipment 

•  Training /Trainers 

•  Tech  orders . 

2.5.2. 1  Test  Subsystem  Production  Costs  -  The  estimate  of  the  test  sub¬ 
system  production  costs  will  be  a  function  of  the  prime  system  characteristics 
such  as: 

•  Size ,  complexity ,  number  of  functions ,  number  of  systems  procured 

•  Characteristics  (RF,  analog,  digital,  etc.) 

•  Performance  requirements  (state-of-the-art,  advanced  state-of-the-art, 
etc. ) 

•  Reliability  and  maintainability  requirements. 

Since  most  of  these  are  evolving  during  the  Conceptual  Phase,  the  cost 
estimating  approach  should  relate  the  prime  system  characteristics  to  the  test 
subsystem  performance  requirements. 

Assume  that  alternate  system  concepts  have  progressed  to  the  point  that 
the  following  are  available: 

•  Prime  system  performance  requirements 

•  Level  I  and  II  functional  flow  diagrams,  Requirement  Allocation  Sheets 
and  their  associated  time-lines 

•  Conceptual  levels  of  maintenance  and  logistic  support. 
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From  these  data,  it  is  feasible  to  estimate  the  prime  system  production 
costs  using  historical  data,  or  the  "Price  Models"  for  electronic  systems  hard¬ 
ware  and  software  or  the  "Modular  Life  Cycle  Cost  Model  (MLCCM)"  for 
avionic  systems. 

Given  that  the  characteristics  of  the  prime  system  design  are  known,  the 
maximum  production  costs  for  its  test  subsystem  can  be  estimated  using  the 
relationship  between  test  subsystem  performance  and  the  prime  system  pro¬ 
duction  cost  of  Fig.  2-12. 

The  relationships  and  data  of  Fig.  2-12  are  subject  to  important  guidelines 
and  constraints  as  follows : 

•  The  percentage  of  prime  system  production  cost  is  relative  to  the 
portion  of  the  system  supported  by  the  test  subsystem 

•  The  data  of  Fig.  2-12  apply  equally  to  avionics  and  ground  elec¬ 
tronics.  They  do  not  apply  to  eiectro-mechanical  or  electro-optical 
systems 

•  The  resulting  typical  production  cost  estimate  is  for  AGE  or  PM /BIT 
and  includes  the  cost  of  the  performance  monitor  function 

•  The  costs  are  for  fault  isolation  to  the  LRU . 

2. 5. 2. 2  Initial  Support  Costs  -  During  the  Conceptual  Phase,  initial  support 
costs  are  usually  estimated  from  both  historical  data  for  similar  weapon  systems 
and/or  as  a  historical  percentage  of  weapon  system  production  costs.  Neither 
of  these  methods  provides  an  accurate  estimate.  However,  a  satisfactory  "not 
to-exceed"  cost  estimate  will  result  if  the  analysis  is  concentrated  on  major 
cost  elements  and  the  factors  which  drive  them.  Initial  support  costs  for  both 
avionics  or  ground  electronic  systems  include  all  logistic  support  elements  re¬ 
quired  to  make  the  prime  system  operational.  Spares,  support  equipment, 
initial  training,  unique  training  equipment,  and  the  Technical  Orders  are  the 
major  cost  elements. 

As  shown  in  Fig.  2-13,  the  initial  spares  and  support  equipment  account 
for  over  70%  of  the  initial  support  costs.  They  are  driven  by: 
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Fig.  2-12  Hypothetical  Relation  Between  PM/BIT  Performance  and  Acquisition  Cost 
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•  Reliability  and  maintainability  characteristics 

•  The  number  of  systems  produced,  the  number  of  systems  per  site, 
and  the  number  of  depots  and  training  sites 

•  The  system  duty  cycle  and  the  support  equipment  workload 

•  Intermediate  and  depot  turnaround  time. 

Development  of  initial  support  costs  is  not  a  subject  of  this  study. 

Rather,  the  question  to  be  answered  is  "How  does  the  test  subsystem  design 
impact  the  initial  support  costs?"  The  following  guidelines  are  provided  in 
response  to  this  question. 

•  Initial  Outfitting  Spares  -  The  cost  of  initial  spares  is  dominated  by  the 
cost  of  on-site  high  value  LRUs,  the  initial  pipe  line  fill,  and  the  war 
reserve  for  these  expensive  items.  These  high  cost  items  generally  ac¬ 
count  for  over  70%  of  the  initial  spares  costs.  While  these  costs  are  af¬ 
fected  by  the  test  subsystem's  effectiveness,  the  relationship  is  not 
linear.  For  instance,  an  extreme  improvement  in  the  effectiveness  of  the 
test  subsystem  would  not  reduce  the  quantity  of  high  reliability /high 
cost  spares  which  normally  are  provisioned  as  one  per  site.  Based  on 
this  logic,  a  conservative  estimate  of  the  cost  savings  due  to  improved 
test  subsystem  effectiveness  should  be  made.  The  maximum  improve¬ 
ment  that  could  be  made  is  in  the  order  of  10%  to  20%  for  the  cost  of 
initial  spares. 

•  Support  Equipment  -  The  costs  of  organizational,  intermediate,  and 
depot  level  support  equipment  generally  acount  for  20  to  30%  of  initial 
support  costs.  The  cost  of  organizational  level  equipment  is  seldom 
greater  than  20%  of  the  total  support  equipment  costs  even  in  the 
total  absence  of  BIT.  The  savings  due  to  incorporating  a  highly 
effective  BIT  are  directly  proportional  to  the  degree  and  completeness 
of  implementation ,  and  the  consequent  reduction  or  elimination  of  the 
organizational  equipment.  Therefore,  20%  is  the  maximum  cost  reduc¬ 
tion  that  should  be  attributed  to  BIT. 

•  Training,  Trainers,  T.O.'s,  and  Other  -  The  cost  of  these  initial  sup¬ 
port  elements  is  seldom  greater  than  15%  of  the  initial  support  cost. 
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The  elements  of  O&S  costs  listed  below  encompass  the  total  personnel  and 
material  costs  necessary  to  operate  and  maintain  a  weapon  system  over  its  life 
cycle : 

•  Base  Maintenance 

•  Base  Operations 

•  Base  Training 

•  Depot  Component  Repair 

•  Replenishment  Spares 

•  Fuel  and  Consumable  Material 

•  Other. 

Of  the  above  LCC  elements,  only  base  maintenance  is  significantly  impacted 
by  the  O-level  test  subsystem  concept.  Base  maintenance  is  estimated  during 
the  Conceptual  Phase  by  assigning  estimated  or  allocated,  maintenance  manhours 
per  operating  hours  (MMHr/Op.Hr. )  for  ground  electronic  systems  or  mainte¬ 
nance  manhours  per  flight  hour  (MMHr/Flt.  Hr.)  for  avionic  systems. 

The  potential  for  O&S  cost  savings  and/or  cost  increases,  as  a  result  of 
implementing  PM /BIT  vs  the  use  of  external  test  equipment  are: 


Potential 

O&S  Cost  Saving 

Due  to  PM/BIT 

Potential 

O&S  Cost  Increases 

Due  to  PM /BIT 

Reduced  system  checkout  and 
fault  isolation  time,  which 
results  in  reduced  O-level  MMHrs. 

Less  no-defect  removals,  which 
result  in: 

•  Reduced  O-level  MMHrs 

•  Reduced  I-level  MMHrs 

•  Reduced  D-level  MMHrs. 

Degraded  system  reliability  due  to  the 
addition  of  BIT  results  in  additional 
failures  and: 

•  Increased  O-level  MMHrs 

•  Increased  I-level  MMHrs 

•  Increased  D-level  MMHrs. 
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Given  that  both  PM /BIT  and  the  external  test  equipment  are  equally  well 
designed ,  it  is  most  likely  that : 

•  System  reliability  will  not  be  significantly  degraded  by  the  implemen¬ 
tation  of  PM /BIT  (This  will  only  be  true  if  extensive  performance 
monitoring  is  a  system  requirement  and  the  added  BIT  is  highly  reliable) 

•  System  checkout  and  fault  isolation  times  will  be  reduced 

•  No-defect  removals  will  be  significantly  less  due  to  the  implementation  of 
PM /BIT. 

Significant  or  insignificant  as  the  first  two  items  may  be ,  it  is  virtually 
impossible  to  estimate  with  accuracy  the  cost  impact  of  "system  reliability  degra¬ 
dation"  and  "system  checkout  time  reduction"  during  the  Conceptual  Phase. 
Therefore,  consideration  of  potential  cost  savings /increases  due  to  these  items 
should  be  deferred  until  the  System  Design  Phase. 

However,  the  impact  of  a  reduction  in  no-defect  removals  may  be  significant 
and  should  be  assessed.  PM/BIT  is  expected  to  change  the  required  MMHr  for 
organizational  maintenance  over  the  total  life  cycle  as  expressed  by  the  following 
equation: 

AO-Level  Cost  =  M  x  T  (UT2  -  UT1)  LR  (Eq.  22) 

where  M  =  Estimated  O-level  MMHr  per  operating  hour  for  ground  electronics  ov 
the  estimated  O-level  MMHr  per  flight  hour  for  avionics ,  T  =  Total  operating 
hours  or  flight  hours  over  the  total  life  cycle  for  the  system  or  aircraft,  = 
Estimated  Uncertainty  of  PM/BIT,  UT2  =  Estimated  Uncertainty  of  external  ttsf 
equipment ,  and  LR  =  The  cost  of  a  direct  maintenance  man-hour  as  defined  in 
Appendix  A,  paragraph  3.3. 

2.6  SELECTION  OF  THE  TEST  SUBSYSTEM  CONCEPT  (STEP  4) 

Mission,  performance,  and  availability  requirements  for  current  military 

aircraft  have  dictated  mean  turn-around  times  in  the  order  of  30  minutes  or 

less.  This,  coupled  with  the  sensitivity  of  the  prime  systems  availability  to  the 

test  subsystems  performance  (i.e. ,  ^ct  ratios  of  0.01  and  greater)  limits 

MTBF 

consideration  of  alternates  to  fully  automatic  BIT  with  fault  isolation  to  the  LRU 


level.  Similarly,  ground  electronic  systems  whose  operational  demand  is  "essen- 

KT 

tial  and  continuous"  or  "essential  and  random"  with  ct  ratios  in  the  order  of 

MTBF 

0.01  and  greater  require  fully  automatic  BIT  with  fault  isolation  to  the  LRU. 

Cost  effectiveness  and  risk  trade-offs  are  used  to  select  the  test  subsys¬ 
tem  concept  when  operational  demand  is  not  critical  and  the  prime  systems  avail- 

Kf 

ability  is  relatively  insensitive  to  the  test  subsystems  performance  (i.e. ,  ct 

MTBF 

ratios  of  0.01  or  less).  For  such  systems,  a  trade-off  considering  cost  alone 
will  generally  drive  the  decision  towards  external  test  equipment.  This  cost 
advantage  must  be  carefully  weighed  against  the  increased  effectiveness  and  re¬ 
duced  maintenance  skills  made  possible  by  PM/BIT.  On  the  other  hand,  the 
risk  element  generally  would  favor  external  test  equipment  for  a  simpler  system 
and  PM/BIT  for  a  large  complex  system.  Thus,  the  choice  is  unique  for  each 
individual  prime  system  and  its  inherent  characteristics. 

2.7  TEST  SUBSYSTEM  REQUIREMENTS  SPECIFICATION  (STEP  5) 

The  objective  of  the  Conceptual  Phase  is  to  translate  an  operational  need 
into  documents  used  to  select  the  most  cost-effective  system  during  the  System 
Design  Phase. 

These  include: 

•  The  Program  Requirements  Baseline  -  which  includes  Functional  Flow 
Diagrams ,  RASs  and  Time  Lines 

•  A  Broad  System  Performance  Specification  such  as  MIL-STD-490  Type 
A  Format 

•  Preliminary  plans  and  conceptual  documents  describing  the  operational, 
logistics,  support  and  maintenance  concepts 

•  Preliminary  cost  and  schedule  estimates  where  LCC  estimates  and  design 
to  cost  targets  are  provided. 

These  system  engineering  documents  are  supported  by  preliminary  acqui¬ 
sition  and  management  planning  documents  and  directives  including  the  Program 


Management  Plan,  the  Request  for  Proposal,  and  the  Statement  of  Work  which 
describe  the  scope  of  the  system  designers  efforts  for  the  next  phase. 

2.7.1  System  Performance  Specification 


The  Program  Requirements  Baseline  Data  provide  the  basis  for  the  Pre¬ 
liminary  System  Performance  Specification.  These  documents  have,  in  the  past, 
frequently  specified  the  system  performance  parameters  while  ignoring  or  defer¬ 
ring  the  test  subsystem  performance  until  later  phases. 

To  optimize  the  test  subsystems  performance  and  design  the  following  prime  system  and  test 
subsystem  performance  parameters  must  be  provided  in  the  System  Performance  Specification. 

•  Operational  demand  and  criticality 
0  Mission  duration  and  operational  modes 

0  Mission  reliability 

0  BITMTBF 

0  Maximum  turn-around  time  (as  applicable) 

0  Allowable  mean  down  time  (as  applicable) 

0  Expected  mean  logistics  and  administrative  delay  times  (ffl]  and  Mq) 

0  Mean  corrective  maintenance  time  ( Mct) 

0  Test  subsystem  Effectiveness  ( Ef) 

0  Percentage  of  false  alarms,  no  defect  removals  (FA). 

2.7.2  Preliminary  Plans  and  Conceptual  Documents 

The  preliminary  operational,  maintenance,  and  logistic  support  plans  should  provide  the  fol¬ 
lowing  system  and  test  subsystem  design  concepts  as  a  minimum: 

0  The  Operational  Concept  which  includes: 

-  The  man/machine  operator  interface  definition 

-  Performance  monitor  requirements  at  the  operator  interfacefs)  and/or  remote 
interfaces 
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-  The  selected  test  subsystem  concept  ( i.e. ,  PM  /BIT  or  external  test  equipment  or  a 
combination  of  both) 

-  The  degree  of  automation  desired  (fully  automatic  or  semiautomatic)  or  t<  e  criteria 
for  trading  off  and  selecting  automatic  ps  semi-automatic 

-  The  level  of  fault  isolation  to  be  accomplished  by  the  test  subsystem  (i.e.,  subsys¬ 
tem,  LR  U,  or  module) 

-  The  desired  maintenance  manning  and  skill  levels 

-  The  desired  MMHr/OP  HR 

-  The  O-level  maintenance  constraints,  including  facilities  and  environments. 

•  The  0-Level  Logistic  Support  Concept  which  includes: 

-  The  O-level  supply  concepts  including  the  mean  logistic  and  administrative  delay 
times 

-  The  O-level  general,  standard  and/or  peculiar  test  equipment  which  is  available  on 
site  to  support  the  system. 

2.7.3  Request  for  Proposal  (RFP)  and  Statement  of  Work  (SOW) 

The  two  most  important  considerations  in  drafting  the  RFP  and  SOW  are  the 
technical  risk  and  complexity  of  the  procurement  and  the  confidence  in  the  esti¬ 
mated  costs.  In  previous  discussions  it  has  been  shown  that  the  test  subsystem 
is  a  high  technical  risk  element  of  the  conceptual  design.  This  is  because  of  the 
lack  of  historical  cost  data  and  the  resulting  lew  confidence  in  the  estimated  cost 

By  setting  Design-to-Cost  (DTC)  targets  for  the  test  subsystem  within  the 
SOW,  emphasis  will  be  placed  on  achieving  the  specified  test  subsystem  perfor¬ 
mance  at  the  specified  cost.  The  DTC  target  should,  at  the  conceptual  level  of 
design ,  be  an  acquisition  cost  target  expressed  as  a  percentage  of  the  systems 
acquisition  costs. 


Life  cycle  cost  estimates  for  the  alternate  candidate  prime  systems  and  test 
subsystems  should  be  required  to  provide  the  visibility  and  detail  necessary  to 
evaluate  the  impact  of  alternate  test  subsystems  on  the  total  life  cycle  cost. 


3.  DESIGN  GUIDELINES  AND  PROCEDURES  -  SYSTEM  DESIGN  PHASE 


Frequently,  the  system  design  process  ha3  treated  test  subsystem  per¬ 
formance  and  costs  as  a  third  or  fourth  order  effect,  if  at  all.  The  net  result 
is  that  the  prime  equipment's  performance  requirements  are  achieved  at  the 
lowest  possible  procurement  costs.  However,  the  test  subsystem's  lack  of  per¬ 
formance  is  usually  not  visible  prior  to  deployment . 

As  will  be  shown,  the  system  engineering  procedures  of  AFSCP  800-3  and 
AFSCM  375-5  provide  all  necessary  tools  and  techniques  to  optimize  the  test  sub¬ 
system  performance,  but  only  if  the  test  subsystem  is  recognized  and  accepted 
as  a  major  determinant  of  LCC .  The  DoD  system  analysis  and  design  procedures 
need  not  be  altered  to  optimize  the  test  subsystem.  Rather,  the  tools  of  sys¬ 
tem  analysis,  when  properly  applied  and  emphasized,  will  provide  the  optimized, 
cost  effective  test  subsystem. 

The  initial  task  of  the  System  Design  Phase  as  illustrated  in  Fig.  3-1  is  to 
extend  the  Conceptual  Phase  functional  analysis  to  the  subsystem  level.  The 
functional  baseline  requirements  of  the  Conceptual  Phase  are  allocated  to  subsys¬ 
tems  via  sub-functional  flow  diagrams.  The  performance  and  design  require¬ 
ments  for  each  sub-function  are  specified  in  Requirement  Allocation  Sheets  and 
time  lines  consistent  with  the  mission  and  performance  requirements  of  the  Con¬ 
ceptual  Phase  System  Specification.  The  test  subsystems  performance  require¬ 
ments  are  defined  for  each  subsystem.  Alternate  test  subsystem  concepts  are 
defined  for  each  subsystem  and  the  LCC  cost  impact  of  alternate  concepts  is 
evaluated  to  select  an  optimum  test  subsystem.  Thus,  the  guidelines  and  test 
subsystem  optimization  procedures  of  the  Conceptual  Phase  apply  equally  to  the 
System  Design  Phase  with  the  exception  that  they  are  carried  out  at  the  subsys¬ 
tem  level. 

Therefore,  in  the  paragraphs  that  follow,  the  methodology  relies  on  the 
Conceptual  Phase  design  procedures.  Also,  for  clarity,  the  many  repetitive 
iterations  of  system  design  have  been  omitted. 

As  depicted  in  the  simplified  flow  diagram  of  Fig.  3-2,  the  system  functional 
analysis  must  be  carried  out  in  sufficient  depth  and  detail  to  permit  specifica¬ 
tion  of  the  subsystems  performance  parameters  and  time  lines  prior  to  test  sub¬ 
system  design  ana  optimization.  The  first  steps  in  the  procedure,  the  reliability 
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Fig.  3-1  System  Engineering  Process  -  System  Design  Phase 


and  maintainability  analyses,  are  pivotal  in  achieving  an  optimized  design.  They 
must  therefore  be  based  on  an  in-depth  knowledge  of  the  subsystem’s  functions, 
performance  parameters,  and  time  constraints. 

3.1  QUANTIFICATION  OF  SUBSYSTEMS'  RELIABILITY  AND  MAINTAINABILITY 

PARAMETERS  (STEP  1) 

The  basic  procedure  of  translating  the  system's  reliability  and  maintainabil¬ 
ity  parameters  into  subsystem  parameters  for  each  subsystem  is  as  depicted  in 
Fig.  3-3.  As  shown,  the  test  subsystem  is  a  major  determinant  of  cost  and  per¬ 
formance.  Subsystem  reliability  is  driven  by  mission  requirements,  and  main¬ 
tainability  is  constrained  by  physical,  environmental  and  operational  require¬ 
ments. 

3.1.1  Quantification  of  the  Subsystem's  Reliability  Requirements 

The  specified  weapon  system  reliability  parameter  is  based  on  mission  re¬ 
quirements  and  therefore  cannot  be  traded  off.  The  reliability  parameters  are 
allocated  per  MIL-STD-756A ,  based  on  mission  reliability  requirements  for  each 
particular  subsystem,  the  subsystem  criticality,  and  safety  of  flight  considera¬ 
tions  for  avionics  or  operator  safety  for  ground  electronics.  The  system  de¬ 
signer  strives  to  incorporate  the  technology  necessary  to  achieve  the  required 
reliability.  Redundant  subsystems  or  portions  of  a  subsystem  may  be  specified 
as  an  alternative  to  the  risk  and  cost  of  new  developments.  As  shown  in  Fig. 
3-3,  it  is  mandatory  that  the  allowable  PM /BIT  reliability  be  assessed  for  each 
subsystem,  and  included  in  the  mission  reliability  specification.  It  is  equally 
important  that  the  required  (acceptable)  PM/BIT  reliability  be  specified  as  a 
test  subsystem  performance  requirement. 

3.1.2  Quantification  of  the  Subsystem's  Maintainability 

Maintainability  analysis  for  both  avionics  and  ground  electronics  is  per¬ 
formed  as  an  integral  part  of  the  total  weapon  system  analysis.  As  shown  in 
Fig.  3-3,  the  goal  is  an  optimized  maintenance  system  for  the  entire  aircraft  or 
ground  system,  with  each  subsystem's  contribution  constrained  to  achieve  the 
specified  weapon  system  maintainability  goal. 

The  procedure,  as  detailed  in  M1L-HDBK-472 ,  is  one  of  allocating  main¬ 
tainability  parameters  (such  as  ST  ,  MMHR/OP.HR,  MMHR/FLT  HR.  etc.)  for 
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the  total  prime  system  into  the  classical  maintenance  elements  for  each  sub¬ 
system  : 

•  unscheduled  maintenance 

•  scheduled  maintenance 

•  support  actions. 

In  the  prime  system  design  process  each  of  these  elements  must  be  mutual¬ 
ly  optimized.  However,  in  the  test  subsystem  design  and  optimization  process, 

M  ,  (which  is  the  O-level  unscheduled  maintenance)  is  of  prime  concern  since 
it  is  the  measure  of  the  test  subsystem's  performance. 

The  allocation  of  O-level  maintenance  parameters  is  initiated  by  evaluating 
the  timelines  of  the  subsystem  level  functional  analysis,  the  subsystem's  as¬ 
signed  reliability,  its  functional  and  physical  characteristics  and,  most  impor¬ 
tant,  its  packaging  and  location  within  the  aircraft  or  within  the  ground  elec¬ 
tronic  equipment.  Given  these  data,  the  O-level  maintenance  time  lines  for  each 
subsystem  are  prepared  to  specify  allocated  times  for  each  subelement  of  Mct, 
including: 

•  preparation  time 

•  access  time 

•  fault  isolation  time 

•  correction /repair  time 

•  performance  verification  test  time. 

These  classical  elements  of  O-level  M  t  may  seem  academic  and  theoretical. 
They  are  not.  For  instance: 

•  Preparation  Time.  Hydraulic,  electric,  and  air-conditioning  carts  are 
required  for  checkout  of  subsystems  without  main  engine  power.  Stands, 
lifts,  and  dollies  are  required  for  personnel  access  to  high  and  inacces¬ 
sible  areas 

•  Access  Time  and  Correction  Time  -  Access  doors  require  latching/ 
unlatching  of  from  4  to  40  and  even  more  "quick  acting"  fasteners. 


Electronics  are  frequently  (of  necessity)  stacked  two,  three,  or  more  deep 

within  an  electronics  bay. 

The  lapsed  maintenance  time  spent  in  the  above  activities  (frequently  15 
to  30  minutes  or  more)  generally  far  exceeds  the  PM /BIT  or  most  external  test 
equipment  test  times  of  2  to  3  minutes  or  less.  The  above  realities  lead  to  the 
conclusion  that  the  currently  specified  maintainability  requirements  for  state- 
of-the-art  subsystems  with  critical  operational  demand  will  continue  to  be  in 
the  order  of: 

•  an  Mfct  430  min 

•  a  fully  automatic  fault-detect  and  isolation  capability  4  5  min 

•  a  functional  test  time  after  maintenance  of  4  3  min 

•  having,  with  very  few  exceptions,  no  manual  fault  diagnostics 

•  having  on-equipment  storage /recording  of  subsystem  failures 
with  automated  print-out. 

The  system  designer,  in  his  effort  to  optimize  Mct,  is  also  constrained  by 
many  other  maintenance  considerations.  A  most  important  constraint  is  person¬ 
nel  quantities  and  skills.  Crew  size  and  the  O-level  maintenance  squad  capa¬ 
bilities,  together  with  the  availability  of  ground  support  equipment  and  facili¬ 
ties,  are  reflected  in  the  preparation  of  the  maintenance  timelines  for  each  sub¬ 
system.  Having  incorporated  all  of  these  considerations  into  the  allocated  sub¬ 
system  Mc(. ,  it  is  necessary  to  evaluate  the  composite  average  M  ^  for  the  over¬ 
all  system.  This  is  calculated  using  the  following  equations: 


>iUT.  Mct. 
1  1 


M  .  = 
ct 


(Eq.  23) 


where  n  =  the  number  of  subsystems,  =  the  estimated /allocated  test  uncer¬ 
tainty  for  each  subsystem,  M  =  the  estimated /allocated  mean  corrective  main¬ 
tenance  time  for  each  subsystem,  andA^  -  the  estimated /allocated  failure  rate 
for  each  subsystem. 


(Eq.  24) 


n 


U 


T 
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where  X  =  the  system's  failure  rate,  U^,  =  the  system's  test  uncertainty,  X^  =  the 
subsystem's  reliability,  U^,  =  the  subsystem's  test  uncertainty,  and  n  =  the 
number  of  subsystems.  1 

A  comparison  of  Equation  23  above  with  Equation  7  of  paragraph  1.6.6  will 
show  that  the  only  change  is  that  the  failure  rate  has  been  multiplied  by  the 
test  subsystem  uncertainty  to  account  for  the  impact  of  no  defect  removals. 

The  problem  remaining,  then,  is  the  selection  of  Test  Uncertainty  (UT  ) 
for  each  subsystem.  Since  each  subsystem  is  unique  in  its  function,  criticality 
and  characteristics,  the  overriding  criteria  which  will  determine  the  selected 
test  subsystem  E,p  are  also  unique.  The  curves  of  Fig.  3-4  are  a  logical 
starting  point  in  selecting  ET  ,  with  resulting  test  subsystem  cost  limits.  The 
subsystem  breakpoint,  as  identified  in  Fig.  3-4,  will  provide  the  maximum 
avionic  system  test  effectiveness  (minimum  test  uncertainty)  per  unit  produc¬ 
tion  cost.  Using  these  points,  the  resulting  avionic  or  ground  electronic  Sys¬ 
tem  Uncertainty  (UT)  should  be  calculated  per  Equation  24. 

At  this  point,  the  system  designer  has  sufficient  visibility  and  mathemati¬ 
cal  tools  to  adjust  the  "breakpoint"  UT  for  each  subsystem  based  on  engineering 
judgment  and  qualitative  factors  such  as: 

•  mission  criticality 

•  safety  of  flight  or  operation 

•  state-of-the-art  technology 

•  PM /BIT  reliability  penalty. 

Sucoessive  iterationfe.of  Uj  into  Equation  23  for 
UT ,  will  result  in  optimized  values  of  Mct ,  ET  or  U^, , 


M  ^  and  Equation  24  for 
and  production  cost. 
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TEST  SUBSYSTEM  ACQUISITION  COST  AS  A  %  OF 
SUBSYSTEM  ACQUISITION  COSTS 


3.2  EVALUATE  TEST  SUBSYSTEM  DESIGN  CONCEPT  FOR  SUBSYSTEM 


CANDIDATES  (STEP  2) 

The  purpose  of  the  system  and  subsystems  functional  analysis  thus  far 

* 

has  been  to  determine  the  operational  and  maintenance  requirements  that  must 
be  met.  These  requirements  (which  cannot  be  traded  off)  provide  the  basis 
for  evaluating  and  trading  off  prime  subsystem  candidates.  Often  the  logical 
subsystem  choice  is  an  off-the-shelf  design.  On  the  other  hand,  it  is  very 
unlikely  that  the  off-the-shelf  candidate  subsystem  will  have  the  desired  PM /BIT 
characteristics.  The  approach  that  is  frequently  taken  is  to  select  the  existing 
candidate  subsystems  which  most  nearly  meet  the  prime  system  performance 
and  production  cost  goals.  The  test  subsystem's  requirements  are  then  mod¬ 
ified  to  accept  the  available  candidate's  "test"  characteristics  without  regard 
to  degradation  of  PM /BIT  performance  and  the  resulting  increase  in  operation 
and  support  costs.  While  this  approach  is  clearly  unacceptable,  current 
systems  procurement  practices  seldom  invoke  a  requirement  to  evaluate  the  LCC 
impact  of  the  resulting  test  subsystem.  An  exception  is  MIL-STD-1591,  which 
provides  the  criteria  for  conducting  trade  studies  and  the  analysis /synthesis 
of  aircraft  BIT  using  an  LCC  model. 

3.2.1  BIT  LCC  Trade-Off  Model 

The  reasons  for  using  a  model  are  to  provide  uniform  criteria  and  a  consis¬ 
tent  cost  accounting  structure  for  LCC  evaluations  and  trade-off  studies.  The 
strict  discipline  inherent  in  a  programmed  procedure  assures  the  design  engi¬ 
neer  that  all  relevant  cost  elements  have  been  included.  The  standard  cost 
elements  in  the  pre-programmed  equations  are  conveniently  provided  to  the 
system  designer.  Therefore,  using  criteria  and  logic  similar  to  the  cost  model 
of  MIL-STD-1591,  a  model  for  test  subsystem  trade-offs  was  developed  and  is 
documented  in  Appendix  A-Life  Cycle  Cost  Trade-off  Model. 

3.2.2  BIT  LCC  Trade-off  Model  Equations 

Implementation  of  a  given  BIT  feature  will  affect  the  RDT&E,  acquisition, 
operational  and  support  costs  and  availability  of  the  host  system.  Thus,  the 
incremental  change  in  life  cycle  cost  is  the  sum  of  incremental  changes  in 
these  cost  categories  as  discussed  in  the  following  paragraphs. 


ALCC  =ARDT&E  Cost  +  A  Acquisition  Cost  + 

A  Operation  and  Support  Cost  + 

A  Availability  Cost  +  A  Flight  Penalty  Costs 


(Eq.  25) 


The  decision  for  each  trade-off  takes  the  form  of  a  question:  "Does  the 
life  cycle  cost  of  the  system  increase  or  decrease  if  this  feature  is  incorpo¬ 
rated?"  If  there  is  a  decrease,  then  the  feature  is  accepted.  Conversely,  if 
there  is  a  null  result  or  an  increase,  the  feature  is  rejected.  All  individual 
terms  are  of  negative  sign  for  a  cost  decrease  or  positive  for  a  cost  increase. 
Total  life  cycle  cost  incremental  change  for  each  category  is  defined  by  the 
following  terms: 


ARDT&E  Cost  =  C 


(Lt.  26) 


where  Cp  is  the  research,  development,  test  and  evaluation  costs  necessary  to 
develop  new  (beyond  the  state-of-the-art)  BIT  technology  and  to  reduce  it  to 
practice. 


AAcquisition  =  C^  +  C^  +  Ct  +  C^g 


(Eq.  27) 


where  Cd  is  the  incremer.  al  change  in  design  cost  due  to  the  postulated  BIT  fea¬ 
ture^),  Cp  is  the  production  cost  of  that  BIT  feature(s),  Ct  is  the  incremen¬ 
tal  change  in  the  cost  of  test  equipment  and  test  software  as  the  result  of  that 
BIT  feature(s) ,  and  C.  is  the  incremental  change  in  the  cost  of  initial  spares 
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out-fitting  resultant  from  that  postulated  BIT  feature(s). 
A  Operation  and  Support  Cost  =  C 


(Eq.  28) 


where  C  is  the  incremental  change  in  operational  and  support  costs  due  to  the 

OS 

postulated  BIT  feature(s). 


A  Availability  Cost  =  C 


(Eq.  29) 


where  C  is  the  incremental  cost  change  required  for  system  procurement  (quan- 
tity)  due  to  availability  changes  resulting  from  the  BIT  feature(s). 


A  Flight  Penalty  Cost  =  C, 


(Eq.  30) 


,where  C^  is  the  flight  penalty  cost  resultant  from  addition  of  the  postulated 
BIT  feature(s),  and  is  null  for  ground  systems. 
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3.2.3  Application  of  the  BIT  LCC  Trade-off  Model 

The  trade-off  procedures  of  the  System  Design  Phase  must  include  the 
evaluation  of  the  test  subsystem  performance  as  well  as  the  evaluation  of  the 
prime  system's  performance,  as  shown  in  the  simplified  flow  diagram  of  Fig.  3-5. 
The  BIT  LCC  trade-off  model  was  designed  to  fulfill  this  requirement.  The  ■ 
model  is  tailored  to  evaluate  only  those  components  of  LCC  that  are  sensitive 
to  the  test  subsystem  cost  and  performance  characteristics.  All  other  elements 
of  the  prime  system's  LCC  are  excluded. 

The  LCC  model,  as  detailed  in  Appendix  A.  is  simple  and  versatile.  Al¬ 
though  the  description  of  the  previous  paragraph  refers  to  trading  off  alter¬ 
native  BIT  features,  the  features  may  be  as  simple  as  alternate  sensor  designs 
or  as  complex  as: 

•  BIT  vs  external  testers 

•  BIT  hardware  vs  BIT  software 

•  centralized  BIT  vs  decentralized  BIT. 

The  model  uses  reliability  and  maintainability  parameters  as  reported  in 
AFR  66-1/65-110  at  the  LRU  level.  The  LCC  elements  for  each  LRU  are  auto¬ 
matically  summed  to  evaluate  subsystem  trade-offs.  Successive  runs  for  each 
subsystem  are  required  to  perform  system  level  trade-off  studies. 

3.3  CONFIGURE  TEST  SUBSYSTEM  ARCHITECTURE  (STEP  3) 

At  this  point  in  the  system  design,  previously  evaluated  candidate  sub¬ 
systems  are  configured  into  competing  systems  and  sized  (space,  weight,  power, 
etc.)  for  the  required  vehicle  or  facility.  Electronic,  electro-mechanical,  and 
optical  interfaces  are  defined  first  in  general  terms  and  then  in  further  detail, 
as  the  iterative  system  design /evaluation  and  trade-off  proceeds.  During  this 
process,  both  the  system  operation  and  control  function  and  the  system  perfor¬ 
mance  monitor /display  functions  must  be  defined  in  detail  prior  to  the  analysis 
and  design  of  the  PM  /BIT  subsystem  architecture. 

Operation  and  control  functions  include  the  man-machine  interface  neces¬ 
sary  to  operate  and  control  the  system  as  a  whole.  The  operator  interface 
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Fig.  3-5  Procedure  for  Evaluating  Existing  Candidate  Subsystem's  BIT  LCC 


m 


determines  the  type  and  character  of  subsystem  controls,  protective  devices, 
and  operational  monitoring  devices.  These,  in  turn,  contribute  to  and  form  a 
part  of  the  BIT. 

Performance  monitor  and  display  functions  encompass  the  displays ,  indica¬ 
tors,  and  alarms  required  to  assure  the  operator(s)  that  mission-critical  func¬ 
tions  are  being  performed.  Included  are  audio  visual  displays  necessary  for  the 
operator  to  perform  alternate  mission  functions,  switch  to  alternate  modes  of 
operation ,  and  take  appropriate  action  to  shut  the  system  down  for  reasons  of 
safety.  Thus,  the  performance  monitor  function  imposes  requirements  for  spe¬ 
cific  sensors,  and  fault  detection  and  diagnostic  capability.  These  will  all  be 
an  integral  part  of  the  PM /BIT.  However,  since  the  performance  monitor  func¬ 
tion  cannot  be  traded  off,  it  must  be  clearly  identified  as  such,  rather  than  as 
an  integral  part  of  the  BIT. 

The  BIT  concept  and  its  architecture  is  not  only  driven  by  the  operator/ 
display  function,  but  also  by  the  system  packaging,  maintenance  philosophy, 
and  support  concepts.  For  example,  the  interface  between  BIT  and  the  organi¬ 
zational  level  maintenance  personnel  may  be  a  single  panel  located  at  the  opera¬ 
tor  interface  or  at  a  remote  location.  On  the  other  hand,  cost,  maintenance, 
and  packaging  considerations  might  dictate  distribution  of  this  function  with  a 
small  panel  for  each  subsystem.  Depending  on  the  M  ^  and  specified,  the 
BIT  function  may  be  fully  automated,  semi-automated,  manual,  or  various  com¬ 
binations  of  these.  The  designer,  in  selecting  from  an  almost  infinite  number  of 
alternatives  will  be  constrained  by  the  PM/BIT  LCC  budget  specified  during 
the  Conceptual  Phase.  The  system  designer's  problem  is  to  select  a  PM/BIT 
subsystem  architecture  tailored  to  the  system  technology  characteristics. 

3.3.1  Avionics  System  PM/BIT  Architecture 

The  requirement  for  a  fully  automatic  test  subsystem  (as  detailed  in  para¬ 
graph  2.4.1)  with  a  minimum  achievable  uncertainty  (Urp)  and  a  mean  time  to 
repair  (Mct)  of  less  than  30  minutes  dictates  the  need  for  a  centralized  test 
program  under  computer  control.  This  program  is  required  to  activate  the  LRUs 
and  their  BIT  circuits  during  preflight,  inflight,  and  postflight  test  routines. 

It  is  also  required  to  recognize  failure  responses  from  the  subsystem  or  LRUs 
and  to  deduce  the  true  failure.  The  central  computer  program  is  required  to 
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process  and  format  both  performance  monitoring  and  BIT  data  for  display  and / 
or  recording. 

For  the  above  reasons,  there  is  no  viable  trade-off  between  a  totally  cen¬ 
tralized  and  a  totally  decentralized  PM /BIT  architecture  in  performing  the 
functions  of  test  initiation,  diagnostics  and  test  data  formatting.  A  central 
processor  is  required  and  will  be  specified  by  the  system  designer  along  with 
the  subsystem's  hardware  and  software  interfaces. 

The  additional  functions  of  thresholding,  deduction,  fault  isolation,  and 
signal  conversion  (to  the  format  of  the  centralized  computer)  must  be  considered. 
For  these  functions  there  is  no  single  optimum  PM /BIT  (centralized  or  decen¬ 
tralized)  architecture,  since  cost-effective  PM /BIT  implementation  depends  on 
the  state-of-the-art  and  technology  of  the  subsystem.  Improved  PM /BIT  con¬ 
cepts  for  avionic  subsystems  have  evolved  rapidly  over  the  past  decade  and 
there  is  every  reason  to  believe  that  this  trend  will  continue.  Two  examples  are 
provided  to  illustrate  this  progress  and  its  current  direction: 

•  F-14A  PM/BIT  (circa  ’70)  -  is  fully  automatic  with  central  computer 
control 

•  ULAIDS  (circa  '80)  -  is  the  Universal  Locator  Airborne  Integrated  Data 
System  which  has  fully  automatic  central  computer  control  PM /BIT  plus 
decentralized  subsystem  microcomputers  and  diagnostics. 

3. 3. 1.1  F-14A  PM/BIT  -  The  F-14A  PM/BIT  provides  rapid,  automatic  check¬ 
out  (less  than  2  minutes)  during  preflight,  postflight,  and/or  inflight  opera¬ 
tion.  It  also  provides  continuous  monitoring  of  vital  performance  functions. 
Figure  3-6,  "F-14A  PM/BIT  Block  Diagram,"  is  illustrative  of  typical  operator 
display  interfaces. 

The  principal  components  of  the  F-14A  PM/BIT  system  are  the  sensors, 
status  indicators,  and  BIT  circuits  of  the  weapon  control  system,  avionics  and 
electro-mechanical  subsystems.  Other  principal  components  are: 

•  AWG-9  Computer 

•  Computer  Address  Panel 

•  Computer  Signal  Data  Converter  (CSDC) 
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Fig.  3-6  F-14A  PM /BIT  Block  Diagram 
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•  AWG-9  Tactical  Information  Display 

•  Horizontal  Situation  Display. 

Timing  and  subsystem  test  initiate  codes  are  generated  in  the  AWG-9  com¬ 
puter  and  transferred  to  the  CSDC.  The  BIT  program  is  stored  in  magnetic 
tape  memory.  The  CSDC  is  the  on-board  computer  input-output  unit  respon¬ 
sible  for  interfacing  with  the  avionics  being  interrogated.  The  CSDC  software 
converts  the  AWG-9  Computer  test  initiate  codes,  and  applies  the  appropriate 
discrete  signals  to  subsystems  under  test  to  remotely  activate  their  PM/BIT. 

The  CSDC  accumulates  the  subsystem  status  and  sends  this  information  to  the 
AWG-9.  Failure  acronyms  are  displayed  on  the  Tactical  Information  Display, 
and  during  ground  checkout  on  the  Horizontal  Situation  Display. 

For  the  F-14,  there  are  three  BIT  routines  stored  in  memory: 

•  Continuous  Monitoring  (CM)  -  The  CM  evaluates  certain  avionics  by  per¬ 
forming  continuous  signal  monitoring  of  individual  subsystem  status. 

The  CM  routine  is  an  integral  part  of  the  tactical  program,  displaying 
system  failure  information  during  normal  tactical  processing.  The 
routine  is  permanently  stored,  and  executed  in  flight  every  two  seconds. 

•  Command  Initiated  Test  (CMD)  -  Command  initiated  tests  are  of  three 
classes:  tests  performed  in-flight  only  because  they  radiate  power, 
tests  which  are  designated  for  preflight  because  a  failure  of  these 
systems  consititues  a  flight  safety  hazard,  and  tests  which  neither 
radiate  energy  nor  relate  to  safety  of  flight. 

•  Maintenance  Readout  (MR)  -  This  routine  is  utilized  during  preflight 
and  postflight  maintenance.  The  MR  routine  cycles  through  a  failure 
history  file  and  displays  LRU  failure  acronyms  on  the  Tactical  Informa¬ 
tion  Display. 

3.3. 1.2  ULAIDS  PM/BIT  -  A  data  bus  design  concept  utilizing  central  computer 
control  and  subsystem  decentralized  microcomputer  controlled  PM /BIT  is  used 
in  the  ULAIDS  system.  In  this  PM /BIT  subsystem  the  computers,  both  central 
and  remote,  are  combined  into  a  multiplexed  network  using  the  MIL-STD-1553 
serial  digital  data  bus. 
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ULAIDS  is  an  airborne  data  acquisition  system  which  monitors ,  records , 
and  displays  the  inflight  status  of  the  airframe,  engine,  and  avionic  components. 
Recorded  data  are  stored  on  magnetic  tape  cassette  for  further  processing  in  a 
gi’ound  terminal  unit . 

Design  features  of  the  ULAIDS  system  are: 

•  Polled  contention  distributed  data  bus  system 

•  Flexibility  -  is  achieved  using  distributed  processing  in  which  each  sub¬ 
system  is  a  "'stand  alone"  intelligent  terminal.  Changes  in  formatting, 
processing,  and  control  can  be  accomplished  under  software  control. 

Any  subsystem  terminal  can  be  reprogrammed  to  accommodate  a  specific 
operational  requirement. 

•  Expandability  -  is  easily  accomplished  by  adding  additional  terminal 
units  to  the  communications  bus 

•  Modularity  -  is  designed-in  through  the  use  of  standard  plug-in  modules 

•  Self-Test  -  is  provided  for  each  functional  module  under  software  con¬ 
trols. 

Figure  3-7  is  a  block  diagram  of  the  ULAIDS  system.  It  consists  of  five 
airborne  stations.  A  ground  terminal  unit  is  also  provided  for  processing  air¬ 
borne  recorded  data.  The  five  data  terminals  are: 

•  Engine  Signal  Acquisition  and  Control  Terminal  (SACT  1) 

•  Aircraft  SACT  (SACT  2) 

•  Aircraft  He;  1th  Monitor  Recorder  (AHMR) 

•  Flight  Incident  Recorder  and  Universal  Locator  (FIR/UL) 

•  Master  Monitor  Display  and  Data  Entry  Panel  (MMD/DEP). 

Each  of  the  subsystems  is  of  the  distributed  processor  type.  i.e.  ,  each 
subsystem  is  capable  of  initiating  communications  with  ether  subsystems  to 
gather  data  or  give  information  regarding  system  failure.  The  individual  sub¬ 
systems  are  self  sufficient  in  that  they  are  capable  of  processing  any  data  that 
is  collected  and  initiating  appropriate  action. 
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Fig.  3-7  ULAtDS  Functional  Diagram 


Signals  received  from  the  aircraft  subsystems  are  processed  in.  real-time 
by  microprocessors  in  the  SACTs.  The  SACT  preconditions,  performs  conver¬ 
sions  ,  and  multiplexes  processed  data  for  transmission  on  either  the  primary 
or  secondary  busses .  Processed  data  is  passed  from  the  SACT  to  other  sub¬ 
systems  for  display  and  recording.  Data  transfers  are  controlled  by  the  AN/ 
AYK-14  computer. 

Each  of  the  major  LRUs  interface  with  the  primary  and  secondary  1553A 
multiplex  data  busses  by  means  of  its  own  microprocessor-controlled  terminal. 
Each  of  these  LRUs  has  the  capability  of  processing  data  and  acting  as  a  remote 
terminal. 

Depending  on  the  established  data  reporting  and  system  priorities ,  certain 
parameters  are  processed  by  the  SACT  and,  upon  detection  of  out-of-tolerance 
conditions  these  parameters  are  passed  to  the  AHMR  for  recording.  Periodic 
"snap-shots"  of  these  parameters  are  also  passed  to  the  AHMR  for  recording. 
They  can  also  be  stored  in  the  non-volatile  memory  of  the  MMD/MT.  Selected 
messages  are  displayed  in  real-time  on  the  MMD  if  any  action  by  the  pilot  can 
alleviate  the  condition  or  if  safety  of  flight  is  threatened.  All  such  data  are 
stored  by  the  MMD  for  post-flight  maintenance  check. 

The  SACT  provides  facilities  for  monitoring  transducer  outputs  and  discrete 
signals.  The  design  is  flexible  to  accommodate  new  or  different  sensors.  Sam¬ 
pling  rates  and  channel  selection  are  internally  programmable  to  facilitate  appli¬ 
cation  of  the  SACT  to  different  engines  and  LRUs. 

3. 3. 1.3  Optimization  of  Avionic  Test  Subsystem  Architecture.  Large  scale 
integration  has  made  microprocessors  readily  available  in  both  MIL  Spec  and 
commercial  versions.  These  components  provide  the  means  to  apply  programmed 
test  sequences  and  to  evaluate  test  results  at  the  subsystem  level.  When  com¬ 
bined  with  data  bus  technology ,  the  microcomputer  provides  the  necessary 
dedicated  interface  to  communicate  with  the  central  computer  with  acceptable 
volume,  weight,  power,  and  cost.  Thus,  the  centralized  computer  with 
distributed  remote  subsystem  terminals  communicating  via  data  bus,  currently 
offers  the  most  advanced  PM /BIT  architectures  for  new  avionic  system  designs. 


78 


Status  word  feedback  to  the  central  computer  enhances  physical  interface 
confidence  and  informs  the  computer  that  a  particular  remote  terminal  has  cor¬ 
rectly  or  incorrectly  received  or  transmitted  data.  Thus,  the  data  bus  protocol 
results  in  a  more  localized  detection  of  a  malfunctioning  subsystem. 

Microprocessor-based  subsystems  allow  more  comprehensive  and  structur¬ 
ally  partitioned  PM /BIT  when  software  controlled.  Thus,  in  conjunction  with 
the  data  storage  capabilities  of  the  subsystem ,  the  data  bus  enables  transmis¬ 
sion  of  a  wide  variety  of  subsystem  signature  data  to  the  central  computer  and 
also  enhances  partitioning  of  each  subsystem's  PM/BIT. 

3.3.2  Ground  Electronic  Systems  PM /BIT  Design 

The  rigid  limitations  of  weight,  volume,  power,  and  cooling  imposed  on  an 
avionic  system  designer  are  not  a  factor  in  ground  electronics  system  design. 
Rather,  these  parameters  are  traded  off  to  achieve  system  performance,  reli¬ 
ability,  tuni  maintainability  at  the  lowest  LCC.  For  example,  redundant  (and 
even  triple  redundant)  systems,  subsystems  or  LRUs  are  often  used  to  achieve 
mission  reliability. 

Diametrically  opposite  to  most  avionic  system  designs,  ground  electronic 
systems  are  designed  to  accommodate  repair  and  replacement  during  system  op¬ 
eration.  This  feature,  coupled  with  redundancy,  not  only  provides  greater 
system  reliability,  but  also  imposes  additional  performance  requirements  on  the 
operator  control  and  PM /BIT  design. 

Since  ground  electronic  systems  are  designed  for  the  less  severe  environ¬ 
ment  of  MIL-E-4158E  vice  MIL-E-5400  for  avionics,  the  incorporation  of  general- 
purpose  computers  and  microcomputers  has  often  been  accomplished  without  the 
costly  RDTftE  effort  to  develop  militarized  versions. 

3. 3. 2.1  Test  Subsystem  Architecture  -  Non-Critical  Demand.  Optimization  of 
the  test  subsystem  architecture  for  ground  electronic  subsystem  whose  required 
Mct/MTBF  ratio  is  in  the  order  of  0.1  or  smaller,  and  having  an  greater  than 
1  hour  is  initiated  with  a  thorough  evaluation  of  both  the  performance  monitoring 
requirements  and  the  maintenance  concept. 
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First ,  the  operator  control  interfaces  and  performance  monitoring  require- 
ments  are  derived  and  specified.  These  requirements,  to  be  included  in  sub¬ 
system  Configuration  Item  Specifications,  include: 

e  the  number  of  operating  personnel  and  their  location 

e  the  operator  interface(s) 

•  displays  required  (central  and/or  distributed  within  the  subsystem)  and 
the  functions  to  be  monitored 

e  the  central  monitor  and  control  interface  signals  and  their  character¬ 
istics,  data  format  and  transmission  means  (to  and  from  the  subsystems). 

Having  selected  the  optimum  control  and  performance  monitor  configuration, 
the  system  designer  still  faces  the  question  of  where  to  place  the  performance 
monitor  signal  processor  and  evaluator. 

The  problem  of  selecting  centralized  vs  decentralized  processing  may  be 
solved  by  cost  considerations  alone  when  a  general-purpose  computer  is  planned. 
However,  there  are  some  negative  factors  in  this  approach: 

•  all  data  must  be  interconnected  to  the  central  processor:  the  connectors 
and  cabling  could  easi'y  become  a  significant  liability 

•  multiplexing  can  reduce  the  number  of  interconnections  at  the  cost  of 
multiplex  interfaces  at  each  terminal 

•  when  the  control  processor  is  down,  the  entire  system  is  inoperable. 

The  question  of  where  to  perform  the  processing  remains.  The  solution 
recommended  is  to  examine  the  interrelation  of  functions  and  then  subfunctions 
within  the  subsystems.  The  system  designer  will  reach  a  level  of  hierarchy 
where  a  particular  group  of  subsystem  functions  are  interrelated  within  them¬ 
selves  but  are  relatively  isolated  from  other  functions  or  sub  functions .  At  this 
level,  deductive  evaluation  of  the  sensors'  output  is  optimally  realized.  Data 
provided  by  the  decentralized  processors  can  be  either  fed  to  a  central  computer 
or  directly  to  the  operator. 
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For  systems  with  non-critical  operational  demand,  the  performance  monitor 
and  data  processing  architecture  are  selected  to  achieve  optimum  total  system 
operation  only.  This  is  not  to  infer  that  the  maintenance  and  test  concepts  are 
ignored.  Rather  the  system  designer  must  optimize  both  in  the  design  of  an 
optimum  system.  The  procedure  for  optimizing  the  maintenance /repair  task  is 
initiated  by  preparing  time-lines  for  the  average  time  required  to  repair  each 
subsystem.  The  Conceptual  Phase  Specification  which  indentifies  personnel  re¬ 
source  constraints  in  terms  of  skills ,  quantities ,  and  maintenance  man-hours  per 
operating  hour  limitations  provides  the  upper  bounds  within  which  the  mainte¬ 
nance/repair  task  times  can  be  allocated. 

While  the  procedure  used  to  prepare  maintenance  /repair  time-lines  for  the 
ground  electronic  system  is  almost  identical  to  that  for  avionic  systems,  the 
constraints  of  the  aircraft  and  avionics  packaging  requirements  are  gone,  sim¬ 
plifying  the  task.  There  are  other  considerations,  however,  which  complicate 
the  analysis,  such  as: 

•  the  distribution  of  the  subsystems  and  AGE  within  the  facility  or  facilities 

•  limited  access  to  certain  equipments  due  to  EMI  shielding,  high  voltage 
barriers ,  and  rotating  equipment  hazards 

•  start-up  and  shut-down  times  for  repair/replacement/retest  for  ground 
electronic  systems 

•  power /weight /volume  may  dictate  repair  in  place. 

Nevertheless,  a  thorough  analysis  of  the  repair  techniques  to  be  applied  and 
detailed  maintenance  time-lines  are  necessary  in  determining: 

•  subsystems  which  require  BIT  and  those  in  which  the  necessity  is 
marginal 

•  subsystems  in  which  the  BIT  should  be  totally  automatic  and  those  in 
which  operator  participation  (with  the  extended  test  times)  is  allowable 

•  logical  location  of  the  centralized  or  decentralized  processor /evaluator 
functions  for  BIT 

•  the  maintenance  parameters  necessary  to  perform  trade-offs  of  alternate 
test  concepts. 


In  performing  such  trade-offs,  the  PM  /BIT  LCC  Model  of  Appendix  A  is 
recommended.  The  proper  application  of  the  model  would  necessitate  successive 
runs  for  alternate  hardware  concepts  in  which  performance  of  the  test  subsystem 
is  held  constant. 

3. 3. 2. 2  Test  Subsystem  Architecture  -  Critical  Operational  Demand  -  Centralized 
performance  monitoring  and  control  capabilities  are  required  to  achieve  contin¬ 
uous  availability  of  a  ground  electronic  system  with  critical  operational  demand. 
Early  Warning,  Command,  Control,  Communication  and  Satellite  Data  Processing 
Systems  will  require  a  general-purpose  computer  or  distributed  microcomputers 
for  PM,  for  switching  to  redundant  units,  and  also  for  off-line  BIT.  The  degree 
of  BIT  or  external  test  equipment  used  to  diagnose  faults  will  depend  on  LRU 
reliability,  criticality,  and  required  Mct.  Thus,  the  optimum  test  subsystem 
architecture  for  ground  electronic  systems  whose  operational  demand  is  essential 
and  continuous,  or  essential  and  random,  is  extremely  similar  to  that  of  avionics. 

The  optimum  test  subsystem  architecture  for  this  category  of  ground  elec¬ 
tronics  should  be  similar  to  that  described  for  the  ULAIDS  system  in  paragraph 
3. 3. 1. 2.  It  should  be  an  integrated  data  bus  system  under  central  computer 
control  with  remote  microprocessor  terminals. 

3.4  SELECT  AND  SPECIFY  TEST  SUBSYSTEM  DESIGN  (STEP  4) 

The  objective  of  the  previous  steps  of  this  procedure  has  been  to  derive 
optimized  test  subsystems  for  each  competing  candidate  prime  system  configura¬ 
tion.  Each  test  subsystem  will  have  been  tailored  to  the  technological  and  phys¬ 
ical  features  of  its  host  system.  Performance  parameters  Mct,  ET,  RBIT  and 
the  LCC  targets  will  have  been  allocated  for  each  subsystem  of  each  candidate 
prime  system. 

The  test  subsystem  selection  process  then  is  not  one  of  trading-off  test 
subsystems,  rather,  the  test  subsystem  will  be  selected  as  a  result  of  trading- 
off  candidate  prime  systems  and  selecting  the  optimum  prime  system  configura¬ 


tion.  However,  the  importance  of  the  test  subsystem  in  these  trade-offs  must 
be  recognized. 
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For  complex  avionic  systems,  the  extensive,  costly  PM  /BIT  hardware  and 
software  may  be  a  major  factor  in  selecting  an  all  new  integrated  suite  vs  exist¬ 
ing  designs.  The  achievement  of  specified  turnaround-time  may  depend  on 
PM /BIT  performance.  The  prime  system’s  LCC  will  be  severely  impacted  by 
PM/BIT  Uncertainty  (UT).  The  impact  of  specifying  PM/BIT  or  an  optimized 
mix  of  PM  /BIT  and  AGE  for  a  ground  electronics  systems  will  generally  have 
significant  impact  on  the  prime  system's  mission  performance  and  resultant  LCC. 

3.4.1  Specification  of  the  Test  Subsystem  Requirements 

The  allocated  design  requirements  baseline  is  an  output  of  the  System  De¬ 
sign  Phase.  It  defines  the  selected  system  configuration  developed  to  satisfy 
the  Conceptual  Phase's  functional  baseline  (program  requirements  baseline) , 
translating  them  into  System  and  Subsystem  Cl  performance  requirements.  The 
resulting  systems  engineering  documents  include: 

•  Program  Requirements  Baseline,  which  includes  Functional  Flow  Dia¬ 
grams,  RAS’s  and  time-lines  carried  to  the  Subsystem  level  and  below 
as  necessary 

•  A  further  refined  system  performance  specification  (MIL-STD-490  Type 
A) 

•  Broad  subsystem  performance  specifications  for  each  development  item 
or  existing  equipment  of  the  prime  system  (MIL-STD-490  Type  B  (Part 

D) 

•  Plans  and  conceptual  phase  documents  expanded  to  describe  subsystem 
operational,  logistics,  support  and  maintenance  concepts 

•  Cost  and  schedule  estimates  for  the  total  system  and  its  subsystems  in¬ 
cluding  LCC  and  design-to-cost  targets  for  levels  1,  2,  and  3  of  the 
Work  Breakdown  Structure  (WBS). 

3.4. 1.1  System  Performance  Specification  -  The  preliminary  System  Specification 
of  the  Conceptual  Phase  must  be  updated  and  expanded  to  encompass  both  the 
total  prime  system's  performance  as  reflected  in  the  characteristics  of  the  sub¬ 
systems  . 


Since  the  test  subsystem  (PM/BIT)  is  distributed  across  the  subsystems,  it  is  of  primary  impor¬ 
tance  that  the  PM/BIT  hardware,  software,  and  subsystem  interfaces  be  documented  in  detail  as 
required  in  Section  3  of  the  Systems  Specification.  The  Integrated  Test  Plan  of  Section  4  must 
identify  evaluation  tests  for  each  performance  parameter  of  Section  3,  and  accept /reject  criteria. 

As  has  been  previously  indicated,  *  is  integrated  test  program  and  the  resulting  corrective  actions 
(design  changes )  are  vital  to  achieving  the  specified  PM/BIT  performance. 

Similar  to  the  Conceptual  Phase,  the  key  test  subsystem  parameters  which  must  be  provided 
in  the  System  Specification,  are: 

•  operational  demand  and  criticality 

•  mission  duration  and  operational  modes 

•  mission  reliability 

•  BIT  circuitry  /software  MTBF  ( expressed  as  a  maximum  percentage  of  the  prime  system 
MTBF) 

•  maximum  Turnaround  Time  (TAT) 

•  allowable  Mean  Down  Time  (MDTQ) 

m  expected  Mean  Logistics  and  Administrative  Delay  Times  (Ml  and  Ma) 

•  the  Mean  Corrective  Maintenance  Time  (Mct) 

9  the  test  subsystem  Effecti veness  ( Ejj 

•  %  False  Alarms  no  defect  removals  (FA). 

3. 4. 1.2  Subsystem  Performance  Specifications  -  The  prime  outputs  of  the  System 
Design  Phase  are  detailed  Specifications  (MIL-STD-490,  Type  B)  for  each  sub¬ 
system.  The  detail  of  these  specifications  with  respect  to  performance,  func¬ 
tional  characteristics,  physical  characteristics,  and  the  integrated  test  plan, 
per  MIL-STD-490,  is  similar  in  content  to  that  of  the  prime  system  specification. 
Functional  and  performance  requirements  are  stated  in  the  broadest  terms  pos¬ 
sible  to  provide  the  subsystem  designer  sufficient  latitude  to  select  an  optimum 
cost-effective  design  and  physical  arrangement  of  the  equipment. 
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As  a  minimum,  each  Subsystem  Performance  Specification  must  include  the  following  test 
subsystem  parameters: 

•  operational  demand  and  criticality 

•  mission  duration  and  operational  modes 

•  mission  reliability 

•  BIT  circuitry  /software  MTBF  ( expressed  as  a  maximum  percentage  of  the  subsystem 
MTBF) 

•  maximum  turnaround  time 

•  allowable  mean  down  time 

•  expected  mean  logistics  and  administrative  delay  times 

•  the  mean  corrective  maintenance  time 

•  The  test  subsystem  effectiveness 

•  %  False  Alarms  no  defect  removals. 

The  system  specifications  must  detail  the  performance  characteristics  of 
the  centralized  PM /BIT  hardware  and  software  and/or  the  selected  external  test 
equipment .  These  details  are  usually  provided  in  the  format  of  separate  speci¬ 
fications  for  the  performance  raonitor/operator  interface  subsystems ,  the  central 
computer /processor  subsystem,  and  the  computer  program  development  specifica- 
x  tion.  Regardless  of  format,  sufficient  interface  detail  must  be  provided  to  per¬ 
mit  the  test  subsystem  design  to  be  optimized  as  a  single  entity.  This  require¬ 
ment  for  interface  data  is  of  prime  importance  for  both  centralized  PM /BIT  and 
for  decentralized  PM /BIT.  This  is  true  since  each  element  of  the  decentralized 
test  subsystem  must  communicate  to  achieve  the  total  prime  system's  PM/BIT 
performance  requirements  even  though  greater  design  latitude  is  available  to  the 
designer  of  decentralized  PM/BIT. 

Subsystem  packaging,  arrangement,  and  physical  characteristics  must  be 
defined  in  quantitative  terms  to  achieve  the  total  system's  mission.  This  is  par¬ 
ticularly  true  of  avionics  where  the  size,  weight,  and  power  of  the  subsystem  is 
critical.  While  the  packaging  arrangement  of  ground  electronics  is  seldom  criti¬ 
cal,  the  requirement  to  define  facilities,  structure,  power  and  cooling,  and  the 


need  for  standardization,  dictates  that  the  packaging,  arrangement,  and  physi¬ 
cal  characteristics  be  defined. 

Therefore,  all  elements  of  organizational  Mct  which  are  a  result  of  the  system  design  must  be 
specified.  These  include: 

•  Preparation  Time  -  Connecting  and  detaching  power,  test  lines,  cooling  and  access  stands 

•  Access  Time  -  Opening  and  closing  doors,  removing  and  reinstalling  panels  and  in-the-way 
components 

•  Correction  Time  -  Removing  and  replacing  the  faulty  unit,  in  place  repair,  adjustment, 
alignment,  or  calibration 

•  Functional  Test  Time  -  Checking  operational  capability  to  verify  the  adequacy  of  correc¬ 
tive  action. 

In  place  repair,  alignment,  and/or  calibration  times  are  also  specified  by  the  system  designer 
and  must  be  in  the  subsystem  specification  together  with  the  required  Mct 

The  remaining  component  of  M£l  to  be  specified  is  the  mean  time  in  which  faults  must  be 
detected,  isolated,  and  displayed  ( M([).  This  parameter  includes  all  diagnostic,  trouble  shooting, 
and  maintenance  technician  participation  time.  It  w ill  be  a  key  test  subsystem  criterion  during 
subsystem  design. 

Specification  of  subsystem  test  and  demonstration  of  each  PM /BIT  perfor¬ 
mance  parameter  is  mandatory  to  assure  that  the  subsystem ,  standing  alone , 
meets  its  performance  requirements  prior  to  initiating  the  total  system's  inte¬ 
grated  test  program.  Section  4  of  the  subsystem  Performance  Specification 
should  include  the  integrated  test  plan  in  which  subsystem  performance  reliability , 
maintainability,  and  the  test  subsystem  requirements  are  demonstrated  and  veri¬ 
fied. 

3. 4. 1.3  Plans  and  Documents  -  A  major  task  of  the  System  Design  Phase  is  to 
finalize  the  Operational  Maintenance  and  Logistic  Support  Plans.  The  preliminary 
plans  of  the  Conceptual  Phase  must  be  expanded  to  include  the  impact  of  deci¬ 
sions  such  as  subsystem  make  or  buy,  Government  Furnished  Equipment  (GFE) 
vs  Contractor  Furnished  Equipment  (CFE),  preliminary  level-of-repair ,  etc. 

These  decisions  will  generally  modify  the  key  elements  of  Conceptual  Phase  pre¬ 
liminary  plans  and  documents. 
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In  updating  and  modifying  the  plans  and  documents,  the  following  test  subsystem  concepts 
should  be  addressed: 

•  The  Operational  Concept 

the  man/machine  operator  interface 

performance  monitor  requirements  at  the  operator  interface! s)  and/or  remote 
alternate  modes  of  system  operation 

•  The  0-Level  Maintenance  Concept 

the  selected  test  subsystem  concept  (i.e.,  PM/BIT  or  external  test  equipment  ora 
combination  of  both) 

the  degree  of  automation  desired  (fully  automatic  or  semi-automatic)  or  the  criteria 
for  trading  off  and  selecting  automatic  vs  semi-automatic 

the  level  of  fault  detection  and  fault  isolation  to  be  accomplished  by  the  test  sub¬ 
system  (i.e.,  subsystem,  LRU,  or  module) 

the  desired  maintenance  manning  level  and  skill  level 

the  desired  MMHR/OP.HR 

The  O-levei  maintenance  constraints,  including  facilities  and  environments. 

•  The  0-Level  Logistic  Support  Concept 

The  O-level  supply  concepts  including  the  mean  logistic  and  administrative  delay 
times 

the  O-level  general,  standard,  and/or  peculiar  test  equipment  which  is  available 
on  site  to  support  the  system. 

•  The  Design-to-Cost  (DTC)  Targets  for  the  Test  Subsystem 

the  design  to  cost  target  should  be  set  by  specifying  the  maximum  acquisition  cost 
of  the  total  test  subsystem  (PM /BIT  and/or  external  test  equipment)  expressed  as 
a  percentage  of  the  avionics  or  ground  electronics  system 's  acquisition  costs. 


4.  DESIGN  GUIDELINES  AND  PROCEDURES  -  SUBSYSTEM  DESIGN  PHASE 


4.1  BACKGROUND  AND  SUMMARY  OF  METHODOLOGY 

This  section  presents  a  straightforward  design  methodology  for  optimizing 
the  types,  quantities,  and  locations  of  BIT  capability.  The  optimal  BIT  design 
is  defined  as  one  which  meets  the  performance  criteria  and  cost  requirements  set 
during  the  System  Design  Phase. 

The  thrust  of  the  optimization  process  is  to  achieve  a  subsystem  design 
which  meets  these  requirements ,  and  which  has  been  further  optimized  for  min¬ 
imal  life  cycle  cost.  The  product  of  the  subsystem  design  is  a  set  of  LRU  re¬ 
quirements  expressed  in  the  individual  specifications  for  the  LRUs  which  com¬ 
prise  the  subsystem. 

During  the  literature  search  a  very  large  body  of  relevant  technical 
material  (specifications,  standards,  technical  papers,  etc.)  was  collected  and 
evaluated.  This  effort  has  identified  a  clear  dichotomy  in  state-of-the-art  BIT 
engineering  methodology: 

•  there  is  a  wealth  of  material  definitive  of  BIT  circuit  design  and  func¬ 
tions 

•  there  is  an  almost  total  absence  of  material  defining  BIT  performance 
criteria,  and  how  BIT  systems  may  best  be  configured  to  meet  defined 
performance  and  cost  goals. 

The  methods  described  in  this  report  are  intended  to  fill  the  need  for  a 
means  of  determining  how  much  "BIT"  a  subsystem  must  have,  how  to  most 
effectively  allocate  that  resource,  how  to  compute,  optimize,  and  measure  the 
resulting  capability. 

The  recommended  methodology  consists  of  seven  procedures,  several  trade¬ 
offs,  and  several  design  guidelines.  These  are  performed  in  the  order  indicated 
by  Fig.  4-1,  which  summarizes  the  process.  Each  procedure  is  a  logical  and/or 


mathematical  process  that  contributes  to  the  development  of  BIT  requirements 
into  an  implemented  BIT  design. 

At  various  steps  in  the  process,  technical  guidelines  are  provided.  These 
are  in  the  nature  of  advisory  considerations,  checklists  of  technical  issues  the 
designer  should  consider,  and/or  design  pitfalls  to  be  avoided.  They  are  in¬ 
tended  to  provide  a  measure  of  guidance  to  the  BIT  designer  by  defining  "good- 
BIT  engineering  practice"  as  distilled  from  the  research  and  experience  of  the 
study  team,  and  should  be  regarded  as  advisory  in  nature. 

The  recommended  design  process  emphasizes  continuity  from  the  beginning 
of  the  subsystem  design  effort  through  the  detailed  design,  and  into  the  actual 
deployment  of  the  product.  The  effectiveness  and  mean  corrective  time  param¬ 
eters  embodied  in  this  methodology  are  suitable  for  derivation  by  a  subsystem 
designer,  for  computation  by  a  detailed  designer,  and  for  measurement  in  the 
deployed  field  organization. 

The  methodology  as  detailed  is  simple,  straightforward,  and  usable  as  a 
day-to-day  engineering  tool.  However,  in  the  mathematical  sense,  global  opti¬ 
mization  of  BIT  would  require  a  universal  solution  of  over  two  dozen  variables: 
this  would  be  too  complex  to  solve  by  known  processes.  Since  the  methodology 
recommended  in  this  document  fills  a  gap  in  existing  engineering  processes,  it 
has  been  deliberately  simplified  to  produce  a  local  optimum  based  on  the  most 
significant  variables  that  must  be  treated  by  the  designer.  This  requirement  is 
imposed  in  order  to  obtain  a  practical  and  usable  process. 

4.2  IDENTIFICATION /ANALYSIS  OF  SUBSYSTEM  FUNCTIONS  (STEP  1) 

This  procedure  is  the  first  step  in  BIT  optimization.  Its  objective  is  to 
define  the  B  IT-related  technical  characteristics  of  the  subsystem  as  early  as 
possible,  and  in  a  form  that  lends  itself  to  subsequent  BIT  design  optimization. 

It  should  be  performed  as  soon  as  quantitative  subsystem  performance  require¬ 
ments  and  at  least  one  candidate  subsystem  architecture  have  been  generated  by 
the  conventional  engineering  process. 

Identifies^ ~  and  initial  analysis  of  subsystem  functions  is  carried  out  by 
generating  three  documents  to  describe  the  conceptual  subsystem  in  terms  of 
functional  flow  and  parametric /modal  characteristics.  These  documents  are: 


•  A  Level  I  Functional  Flow  Block  Diagram  -  this  is  an  overall  diagram 
of  the  conceptual  system  architecture,  showing  its  inputs,  outputs, 
elements ,  and  inter-relationships ;  emphasis  is  placed  on  defining  the 
functional  path  associated  with  each  required  subsystem  function 

•  An  Output  Signal  Matrix  -  this  is  a  list  of  all  signal  outputs,  showing 
their  amplitudes ,  tolerances ,  units ,  etc . ,  by  mode  of  subsystem 
operation;  it  provides  the  "first  cut"  definition  of  what  quantities  must 
be  measured  to  detect  and  isolate  faults 

•  An  Input /Stimulus  Signal  Matrix  -  this  is  a  list  of  all  stimuli  provided  to 
the  system  (again  in  terms  of  units,  amplitudes,  nominal  values,  and 
tolerances)  by  mode  of  subsystem  operation. 

The  above  three  documents  will  become  a  permanent  tool,  and  will  be  used 
and  updated  during  all  phases  of  the  BIT  design  process. 

4.2.1  Design  Guidelines 

BIT  optimization  should  be  carried  out  as  an  integral  part  of  the  subsystem  design  effort,  rather 
than  as  a  separate  effort. 

The  technical  issues  which  must  be  considered  in  order  to  accomplish  the  BIT 
design  are  interwoven  with  most  of  the  normal  efforts  intrinsic  to  the  design  of 
an  electronic  subsystem.  The  information  needed  to  accurately  define  functional 
paths  and  stimuli /response  signals  would  be  difficult  for  a  BIT  designer  to  ob¬ 
tain  unless  he  is  a  part  of  the  design  "team,"  rather  than  an  "outside  specialist." 

A  "Test"  mode  must  be  included  in  every  subsystem  specification,  and  defined  in  the  same 
detail  and  with  the  same  care  as  are  the  requirements  for  every  other  mode  of  the  required 
subsystem. 

Every  electronic  subsystem  must  be  tested  many  times ,  from  the  day  it  is  fabri¬ 
cated  and  delivered  to  the  years  during  which  it  must  be  tested  for  maintenance 
reasons.  It  follows,  therefore,  that  all  systems  should  have  a  test  mode,  and 
that  every  system  function  should  be  designed  to  perform  its  test  function  ac¬ 
curately  and  economically. 


4.2.2  Preparation  of  Level  I  Functional  Flow  Block  Diagram  (Step  1A) 


This  diagram  is  prepared  to  identify  the  required  functions  and  associated 
functional  paths  of  the  subsystem  being  designed.  It  is  an  adaption  of  the 
block  diagram  normal  to  this  stage  of  design,  but  distinguished  by  emphasis 
upon  functional  paths: 

•  FUNCTION  is  defined  as  the  signal  processing  capability  of  the  elec¬ 
tronic  subsystem  being  designed;  the  design  control  specification  will 
identify  required  functions  and  their  parametric  values 

•  FUNCTIONAL  PATH  is  defined  as  the  path  taken  by  subsystem  through¬ 
put,  from  input  to  output,  associated  with  the  given  function.  The 
functional  path  therefore  includes  all  the  subsystem  elements  which 
accomplish  a  function,  and  illustrates  their  inter-relationships. 

Functions  are  candidates  for  either  BIT  or  a  performance  monitoring 
capability.  Functional  paths  are  candidates  for  a  fault  isolation  capability.  The 
intent  of  the  Level  I  Functional  Flow  Block  Diagram  is  to  initially  identify  these 
aspects  of  the  subsystem.  Figure  4-2  illustrates  such  a  diagram,  using  a  con¬ 
ceptual  airborne  radar  subsystem  as  it  might  exist  at  this  point  in  the  design 
effort .  Note  that  the  design  is  diagrammed  as  a  set  of  inter- related  functions , 
and  is  not  yet  necessarily  partitioned  into  physical  subassemblies.  Functions 
are  identified,  and  will  be  subject  to  further  analysis  as  the  design  evolves. 

4.2.3  Preparation  of  Output  Signal  Matrix  (Step  IB) 

This  matrix  is  prepared  to  define  and  characterize  signals  required  for 
testing  the  subsystem.  At  this  stage  of  the  design,  it  is  preliminary.  As  the 
design  effort  progresses,  it  will  be  revised  to  maintain  it  current  at  all  times, 
because  it  will  be  used  as  the  basic  reference  tool  for  the  orderly  and  logical 
design  of  the  test  subsystem. 

The  matrix  will  tabulate  two  general  classes  of  signals  that  must  be  tested: 

•  Primary  Output  Signals  -  these  are  subsystem  outputs  which  must  be 
present  and  correct  in  order  to  obtain  normal  subsystem  performance; 
conversely,  these  are  signals,  the  failure  of  which  denotes  subsystem 
failure 
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•  Secondary  Output  Signals  -  these  are  subsystem  internal  output  signals 
which  are  required  for  fault  isolation  testing  as  they  relate  to  failed 
primary  output;  in  general,  these  signals  do  not  appear  as  subsystem 
outputs  to  the  "parent"  system,  but  usually  appear  at  test  points. 

The  matrix  is  a  tabulation  of  signal  number,  signal  nomenclature,  re¬ 
lated  subsystem  function,  and  signal  properties  by  subsystem  mode.  Figure  4-3 
presents  the  format  of  an  Output  Signal  Matrix,  with  the  data  headings  as  they 
would  appear  for  the  conceptual  radar  of  Fig.  4-2.  Following  are  brief  de¬ 
scriptions  of  the  headings. 

Signal  Number  -  is  a  numerical  descriptor  uniquely  defined  to  identify 
each  particular  signal. 

Signal  Nomenclature  -  is  the  "name"  of  the  signal,  and  should  be  chosen  to 
be  as  descriptive  of  its  nature  as  possible  within  a  reasonable  number  of 
characters . 

Related  Function  -  is  the  name  of  the  subsystem  function  which  this  signal 
partly  or  wholly  implements;  signals  should  be  grouped  together  by  sub¬ 
system  function. 

Function  Number  -  is  the  numerical  descriptor  which  uniquely  identifies 
the  subsystem  function  associated  with  each  signal. 

Class  -  the  class  entry  will  be  "P"  for  primary  signals,  or  "S"  for  secondary 
signals.  The  matrix  should  be  ordered  such  that  the  first  portion  of  tabu¬ 
lated  signals  are  primary  and  the  remainder  are  secondary. 

The  next  several  columns  identify  the  technical  and  parametric  character¬ 
istics  of  the  signals  tabulated ,  in  a  summary  form .  The  precise  terms  used  in 
any  particular  subsystem  effort  will  be  dependent  upon  the  nature  of  the  sub¬ 
system.  For  purposes  of  Fig.  4-3,  the  following  terms  have  been  used  to  de¬ 
scribe  the  properties  of  the  signals  likely  to  be  indigenous  to  the  conceptual 
radar  of  Fig.  4-2: 

Analog  -  in  the  example,  this  column  would  contain  a  blank  for  signals 
characterized  as  non-analog.  For  analog  signals,  a  code  letter  is  assigned 
to  further  define  the  signal,  such  as: 


JITT KH 


•  S :  sawtooth 


•  T :  timing  or  trigger  function 

•  R :  ramp 

•  D:  a  DC  level 

The  set  of  code  letters  are  chosen  by  the  designer,  in  the  above  manner, 
such  that  the  class  of  analog  signals  is  defined  in  a  granular  form  that  he  judges 
to  be  complete  with  respect  to  the  character  of  the  subsystem. 

Digital  -  in  the  example,  this  column  would  be  blank  for  all  non-digital 
signals.  For  digital  signals,  it  would  contain  further  definition  of  the 
signal.  For  example: 

•  Name  -  the  name  assigned  to  the  Boolean  term  implemented  by  this 
signal 

•  Family  -  the  logic  family  used  to  implement  this  signal,  such  as 

-  T:  TTL 

-  M:  MOS 

-  C :  CMOS 

-  I:  I2L 

-  E:  ECL 

and  so  forth,  according  to  the  planned  hardware  designs  and  the 
judgement  of  the  designer. 

•  Format  -  a  code  letter  to  describe  data  format,  such  as  "S"  for  serial, 
"P"  for  parallel,  "A"  for  ASCII,  "M"  for  Manchester,  or  any  similar 
set  of  descriptors  chosen  by  the  BIT  designer. 

Discrete  -  this  column  defines  signals  of  discrete  origin,  such  as: 

•  R:  relay  output 

•  F:  solid  state  discrete  (flag) 

or  any  other  set  of  appropriate  codes  chosen  by  the  designer,  and  would  of 
course  be  left  blank  for  non-discrete  signals. 
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RF  -  this  column  would  be  used  to  characterize  signals  of  an.RF  nature, 
for  example: 

•  T :  Magnetron  output 

•  R:  Receiver  detector  output 

•  I:  Intermediate  signal  frequency 

•  L :  Local  oscillator 
and  so  forth. 

Video  -  this  column  would  be  used  to  characterize  signals  of  a  video  nature, 
by  a  set  of  code  letters  such  as: 

•  C:  Composite  video 

•  M:  Marker  video 

•  R:  Range  line  video 

•  T:  Target  video 
and  so  forth. 

Power  -  this  column  would  be  used  to  characterize  AC  or  DC  power  quanti¬ 
ties  ,  using  codes  such  as : 

•  DC :  for  DC  power 

•  AC:  for  AC  power,  single  phase 

•  A3:  for  AC  and  multiphase  power  (3  denoting  phase  number  three) 
and  so  forth. 

The  next  several  columns  identify  the  parameters  of  each  signal,  by  mode, 
with  tolerances.  They  define  those  quantities  which  must  be  measured,  by 
mode,  to  determine  that  the  signals  tabulated  are  performing  properly  or  have 
failed.  Here  again,  the  contents  of  the  "mode"  columns  will  vary  widely  ac¬ 
cording  to  the  specific  nature  of  the  subsystem  being  designed,  and  is  left  to  the 
judgement  of  the  designer.  In  the  Fig.  4-3  example,  the  following  conventions 
can  be  used  to  characterize  signal  nominal  values  and  tolerances: 


•  Modes  1  through  n:  These  might  represent  the  various  range,  warmup, 
and  standby  modes  of  the  hypothetical  radar,  including  its  test  mode. 
(The  requirement  that  every  signal  have  a  test  mode  is  of  paramount 
importance  for  reasons  explained  earlier.  In  fact,  any  signal  that  can¬ 
not  be  parametrically  described  in  its  test  mode  is  a  signal  which  by 
definition  cannot  be  tested.)  Signals  intentionally  designed  to  be  untest- 
able  should  be  coded  "X"  to  highlight  this  intentional  design  feature. 

•  EMAX,  EMIN,  ENOM,  ZS:  These  codes  might  represent  the  nominal 
value  of  the  signal,  its  maximum  instantaneous  voltage,  its  minimum 
instantaneous  voltage ,  and  its  source  impedance .  If  left  blank  for  a 
given  mode,  this  would  denote  "signal  absent,"  except  that  signals 
absent  in  the  test  mode  should  be  coded  "X."  These  descriptors  would 
locate  the  time  domain  voltage  minima,  maxima,  and  nominal  levels  of  any 
class  of  signal  previously  defined  in  other  portions  of  this  matrix  row, 
to  provide  an  indication  of  measurement  ranges. 

•  FREQUENCY  /TOLERANCE :  The  nominal ,  upper  limit ,  and  lower  limit  of 
this  signal,  in  this  mode,  for  normal  operation. 

•  VOLTAGE/TOLERANCE:  The  nominal,  upper  limit,  and  lower  limit  of 
signal  voltage  in  this  mode,  for  normal  operation,  with  an  indication  of 
how  the  voltage  is  to  be  measured,  i.e.,  DC,  RMS,  peak,  peak-to-peak , 
average,  etc. 

•  TIMING  /TOLERANCE :  For  signals  whose  timing  is  contingent  upon 
triggers  or  clocks,  this  parameter  would  define  when  the  measurement 
is  to  be  made,  the  signal  number  of  the  reference  timing  function,  and 
the  tolerance  in  units  of  time. 

•  JITTER/TOLERANCE :  For  signals  where  jitter  is  a  consideration,  this 
entry  would  define  maximum  allowable  jitter  with  respect  to  average 
measured  time  value. 

•  DISTORTION  /TOLERANCE :  Similarly,  the  distortion  (nominal  and  maxi¬ 
mum)  for  signals  where  this  characteristic  is  of  interest. 

•  OTHER /TOLERANCE:  An  entry  to  define  unusual  testing  parameters, 
and  their  required  nominal  values  and  tolerances. 
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To  the  degree  possible  at  this  stage  of  the  subsystem  Resign,  the  above 
signal  parameters  should  be  defined  by  mode,  to  form  the  basic  definition  of 
quantities  to  be  measured  in  the  subsystem  being  designed.  In  cases  where 
these  parameters  are  not  yet  known,  they  should  be  coded  "TBD"  to  indicate  a 
later  requirement,  or  left  blank  to  denote  that  they  are  not  appropriate. 

The  next  several  columns  identify,  for  each  mode,  the  contingency  of  each 
signal  upon  other  signals,  and  upon  stimuli: 

•  when  a  signal  is  contingent  upon  a  related  signal,  that  related  signal  is 
coded  by  entering  its  signal  number  in  the  "contingency"  columns 

•  when  a  signal  is  contingent  upon  a  stimulus  provided  to  the  subsystem 
during  normal  operation,  the  stimulus  number  is  coded  by  entering  the 
number  preceded  by  an  "S"  in  the  "contingency"  columns 

•  when  the  signal  is  contingent  upon  a  special  stimulus  provided  to  allow 
it  to  be  tested,  then  the  special  stimulus  number  (preceded  by  a  "T") 
is  entered  in  the  "contingency"  columns. 

The  final  group  of  columns  identify  test  strategies  and  related  BIT  design 
data  required  for  optimization.  At  this  stage  of  the  design  effort,  these  will 
almost  always  be  still  undefined.  The  significant  issue  is  that  these  items  are 
included  in  the  matrix  because  they  must  ultimately  be  completed  to  optimize  BIT, 
record  the  results  of  this  effort,  and  permit  systems  evaluation  when  they  are 
ultimately  deployed.  Items  in  this  category  are  denoted  as  follows: 

Frp:  Failure  rate  per  hour  is  required  as  an  input  to  the  optimal  alloca¬ 
tion  of  BIT  test  points,  and  will  be  determined  later  in  the  BIT  effort.  As 
coded  in  the  matrix,  the  figure  is  the  estimated  value  for  all  circuits  be¬ 
tween  stimulus -inputs  and  the  signal  output  in  question,  and  includes 
PM /BIT  failure  rates. 

TEST? :  This  descriptor  is  coded  as  "Y"  for  "yes,"  or  "N"  for  "no."  By 
completion  of  this  entry  for  every  output  signal  of  the  subsystem,  a  deci¬ 
sion  is  forced,  such  that  the  signal  will  be  tested,  or  will  not  be  tested. 

PM  INTRINSIC?:  This  column  is  provided  for  the  BIT  designer  to  indicate 
that  his  analysis  shows  the  signal  to  have  intrinsic  performance  monitoring 
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capability,  or  not  to  have  this  capability.  Many  signals  produced  by  sub¬ 
systems  have  visible  means  by  which  the  operator  may  determine  whether  or 
not  they  are  present.  For  example,  displays  indicate  video  signals,  meters 
are  often  present  to  indicate  voltage  and  current,  etc.  Optimization  of  BIT 
will  make  maximum  use  of  such  intrinsic  capability,  because  it  provides  fault 
detection  and/or  isolation  capability  without  being  chargeable  to  the  test 
subsystem  cost.  This  column  is  provided  to  ensure  that  every  signal  is 
analyzed  for  this  capability,  and  the  results  of  this  analysis  recorded  for 
reference . 

PM  EXTRINSIC?:  Wherever  a  signal  must  be  provided  with  fault  detection 
capability  in  order  to  meet  the  needs  of  the  user  (not  the  maintenance 
personnel) ,  this  descriptor  is  coded  "Y . "  Examples  of  such  signals  might 
be  those  related  to  operational  safety  of  the  system,  flight  safety,  etc. 

Such  capability  must  be  implemented  in  the  subsystem ,  but  its  costs  are 
not  chargeable  to  BIT. 

FAULT  DETECT?:  Whenever  a  primary  output  signal  is  determined  to  re¬ 
quire  BIT  fault  detection,  this  descriptor  is  coded  "Y".  Such  fruit  detec¬ 
tion  may  be  required  to  meet  the  effectiveness  requirement  for  a  BIT  capa¬ 
bility.  Its  costs  are  chargeable  to  BIT. 

FAULT  ISOLATE?:  Whenever  a  primary  output  signal  fails,  fault  isolation 
of  its  secondary  signals  will  be  considered  by  the  BIT  designer.  Whenever 
it  is  determined  that  the  signal  must  have  a  BIT  capability  to  meet  specified 
effectiveness  and  M^,  this  column  will  be  coded  "Y." 

AGE? :  Signals  having  no  performance  monitoring  or  BIT  capability  must 
obviously  be  tested  by  AGE,  unless  there  is  a  design  decision  not  to  test 
them .  For  example ,  if  a  system  specification  required  detection  of  less  than 
all  potential  failures,  it  might  be  decided  that  certain  signals  would  not  be 
tested.  Each  primary  output  that  carries  the  value  "Y"  for  its  "TEST?" 
descriptor,  and  has  neither  PM  nor  BIT,  must  be  coded  for  AGE. 

QUALITY  FACTOR?:  This  descriptor  represents  the  designer's  estimate  of 
the  percentage  of  measurements  at  the  signal  output  in  question  that  cor¬ 
rectly  pass  and/or  fail  a  signal  for  purposes  of  fault  detection.  It  is  used 
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in  combination  with  the  failure  rate  to  calculate  the  overall  effectiveness 
of  BIT.  Any  values  entered  at  this  stage  of  system  design  pre  in  the 
nature  of  "first  cut"  estimates  from  experience,  and  will  be  updated  when 
actual  circuit  design  permits  more  accurate  values  to  be  entered. 

TIME  FACTOR?:  This  descriptor  represents  the  designer's  estimate  of  the 
number  of  minutes  required  for  performance  monitoring,  BIT,  or  AGE  to' 
fault  detect  (for  primary  output  signals),  or  fault  isolate  (for  secondary 
output  signals) .  It  is  used  to  compute  subsystem  mean  corrective  mainte¬ 
nance  time.  For  online  BIT  the  term  is  near  zero,  and  may  be  entered  as 
zero.  For  offline  BIT,  and  for  AGE  tests,  the  term  has  a  finite  value  in 
minutes.  Initial  values  are  an  estimate,  but  should  be  reviewed  and  up¬ 
dated  as  the  design  progresses. 

SAMPLE  RATE /SECOND:  A  descriptor  of  how  often  the  signal  is  tested  by 
BIT.  Depending  upon  the  particular  BIT  circuits  or  capability  implemented, 
this  could  have  values  in  the  following  ranges: 

•  "C , "  for  continuous ,  as  for  example  with  an  analog  output  having  an 
associated  BIT  comparator 

•  every  few  microseconds,  as  for  a  repetitive  digital  signal 

•  at  some  rate  determined  by  a  data  bus  rate 

•  at  times  dependent  upon  system  turn-on,  as  might  be  the  case  with 
offline  BIT 

•  whenever  AGE  is  used,  for  signals  tested  by  AGE. 

The  numerical  value  coded  for  this  descriptor  will  be  used  to  estimate  the 
probability  that  a  given  signal  may  fail  between  test  samples,  and  is  thus 
another  measure  of  how  effective  a  BIT  design  may  prove  to  be. 

$$$$:  The  designer's  estimate  of  the  cost  of  implementing  BIT  for  this  sig¬ 
ned  (viz. ,  the  cost  of  design,  component  parts,  fabrication,  and/or  the  cost 
of  software  programming  for  diagnostics.) 

SENSOR:  The  type  of  BIT  implementation.  Meiny  signeils  will  be  directly 
measurable,  others  will  require  signal  conditioning  or  transducers.  The 


designer  should  code  this  column  with  suitable  descriptors  defining 
that  BIT  actually  implemented. 

EVALUATION :  When  the  evaluation  of  signals  is  local,  this  is  coded  "L," 
or  conversely  "C"  if  central.  When  BIT  is  implemented  by  software  diag¬ 
nostics,  this  could  be  coded  "S." 

4.2.4  Preparation  of  Input /Stimulus  Signal  Matrix  (Step  1C) 

This  matrix  is  prepared  to  define  and  characterize  the  input  signals  and 
test  stimuli  required  for  testing  the  subsystem,  and  is  also  preliminary  at  this 
stage  of  design.  As  the  design  progresses,  it  will  be  reviewed,  updated,  and 
completed  in  final  form .  It  will  be  a  permanent  reference  for  the  design  effort , 
and  will  be  used  to  facilitate  later  evaluation  of  BIT  performance  and  cost. 

The  Input /Stimulus  Signal  Matrix  will  tabulate  two  classes  of  signals  used 
to  test  the  subsystem: 

•  Primary  Input  Signals  -  These  are  stimuli  normal  to  the  operation  of  the 
subsystem ;  they  are  either  provided  from  the  system  interface  by  other 
subsystems  or  are  provided  from  the  system  external  environment,  as 
would  be  the  case  with  such  signals  as  inertial  forces,  flight  displace¬ 
ments,  airspeed  parameters  such  as  pitot  /static ,  or  RF  signals. 

•  Test  Stimuli  -  These  are  stimuli  required  to  test  the  subsystem,  provided 
by  BIT  or  external  test  equipment:  in  general,  they  ire  needed  to  evalu¬ 
ate  system  functions  in  the  absence  of  primarv  input  signals,  since  the 
latter  are  not  developed  with  the  system  in  a  quiescent  state.  Whenever 
an  output  signal  must  be  tested  in  the  absence  of  its  primary  input  sig- 
nal(s),  the  designer  must  of  necessity  provide  corollary  test  stimuli. 

The  matrix  is  very  similar  to  the  Output  Signal  Matrix  defined  in  paragraph 
4.2.3.  It  is  changed  slightly  to  reflect  the  descriptions  of  stimuli  rather  than 
outputs.  The  following  describe  the  columns  in  Fig.  4-4: 

Signal  Number  -  is  coded  as  the  character  "S"  for  a  primary  input,  or  "T" 
for  a  test  stimulus ,  plus  a  number  to  uniquely  identify  the  particular 
signal. 

Signal  Nomenclature  -  is  coded  as  the  name  of  the  signal. 
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Related  Function  -  is  coded  as  the  name  of  the  subsystem  function  whose 
test  is  dependent  upon  the  availability  of  this  stimulus  signal.  Thus,  thi^ 
parameter  identifies  the  relationship  between  stimuli  and  subsystem  func¬ 
tions. 

Function  Number  -  is  the  number  of  the  above  related  function. 

Class  -  this  entry  is  coded  as  "I"  for  primary  input  signal,  or  "T"  for  spe¬ 
cial  test  stimuli  of  BIT  or  AGE  origin. 

The  next  several  columns  identify  the  technical  and  parametric  character¬ 
istics  of  the  input  signals  and  test  stimuli,  in  a  summary  manner.  Again,  the 
specific  descriptors  and  coding  have  been  selected  to  be  appropriate  for  the 
Fig.  4-2  conceptual  radar,  and  must  be  tailored  by  the  BIT  designer  to  suit  his 
particular  subsystem.  Note  that  the  example  matrix  shown  in  Fig.  4-4  has  the 
same  columns  and  meaning  as  did  the  same  portions  of  the  Output  Signal  Matrix 
exemplified  by  Fig.  4-3,  because  the  same  information  is  desired.  However, 
there  is  no  identification  of  signal  contingency  because  Fig.  4-4  is  a  description 
of  stimuli  and  primary  inputs . 

The  remaining  columns  of  the  Input /Stimulus  Signal  Matrix  identify  the 
strategy  chosen  to  generate  each  of  the  stimuli  or  input  signals  and  record  cer¬ 
tain  BIT  design  decisions  and  data  required  for  optimization.  At  this  stage  of 
the  design  effort,  these  columns  will  also  be  blank,  but  again,  ultimately  all 
must  be  filled  to  perform  the  BIT  design  task  properly.  Items  coded  in  these 
columns  are: 

Frj  /Fr p  -  Failure  rate  per  hour  of  this  stimulus  generation  function  which 
may  be  a  functional  element  (Frj)  or  an  input  signal  (Frp). 

TEST?  -  "Y"  for  yes",  or  "N"  for  "no"  to  indicate  whether  this  stimulus 
signal  must  be  tested  to  determine  that  it  is  operative.  For  most  BIT 
implementations,  this  decision  will  usually  be  negative,  while  for  AGE 
stimuli  it  is  expected  normally  to  be  affirmative.  The  intent  of  this  column 
is  to  force  a  decision  on  this  question. 

RATE  -  The  rate  at  which  this  stimulus  is  generated,  ranging  from  continu¬ 
ous,  to  a  system  clock  rate,  or  several  hours  between  applications  for  AGE. 
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CALIBRATION  -  A  descriptor  of  whether  or  not  the  stimulus  function  re¬ 
quires  periodic  calibration,  and  how  often.  Coding  used  would  simply  be  a 
time  interval  or  left  blank  for  stimuli  not  needing  calibration. 

$$$  -  The  total  production  cost,  estimated  by  the  designer,  for  implement¬ 
ing  this  stimulus  signal. 

4.3  FUNCTIONAL  PATH  DEFINITION  (STEP  2) 

Referring  to  the  Fig.  4-1  flow  chart,  the  second  precedure  for  BIT  optimi¬ 
zation  is  to  define  functional  paths  of  the  subsystem  under  design.  This  effort 
is  carried  out  as  soon  as  the  mainstream  subsystem  design  process  has  reached 
a  stage  where  its  functions  have  been  at  least  tentatively  partitioned  into  physi¬ 
cal  subassemblies  or  into  line  replaceable  units  (LRUs). 

Functional  path  definition  is  performed  by  updating  the  Level  I  Functional 
Flow  Block  Diagram  and  signal  matrices ,  and  by  preparing  a  Level  II  Functional 
Flow  Block  Diagram  to  define  the  elements  of  each  individual  functional  path. 
Thus,  every  functional  path  will  be  the  subject  of  an  individual  Level  II  diagram. 

The  products  of  functional  path  definition  are  sufficient  to  describe  the 
subsystem  in  a  form  that  lends  itself  to  subsequent  BIT  analysis  and  optimiza¬ 
tion: 

•  the  updated  Level  I  diagram  defines  the  overall  subsystem  as  the  sum  of 
its  input,  output,  throughput,  elements,  and  inter-relationships 

•  Level  II  diagrams  define  each  functional  path  in  the  same  terms ,  but  in 
a  more  granular  and  detailed  manner 

•  the  signal  matrices  define  the  characteristics  of  all  input,  internal,  and 
output  signals ,  thus  providing  the  parameters  that  quantitatively  de¬ 
scribe  how  elements  process  throughput  to  produce  output 

•  the  signal  matrices  also  provide  a  checklist  of  BIT  design  decisions 
that  will  be  made  during  subsequent  analysis  and  optimization,  and  a 
place  to  record  these  decisions  in  consistent  format. 


4.3.1  Design  Guidelines 

Special  care  should  be  given  to  design  features  that  need  to  be  incorporated  into  a  subsystem 
to  support  its  test  mode. 

At  this  stage  of  the  design  process ,  many  test-related  architectural  fea¬ 
tures  of  the  subsystem  become  defined  and  some  of  these  will  tend  to  inhibit 
economical  testing.  In  particular,  feedback  loops,  test  and  stimulus  access, 
logical  (functional)  partitioning  of  assemblies,  and  cases  where  signals  must 
have  unusually  tight  tolerances  are  of  interest.  The  designer  must  analyze  the 
subsystem  for  these  properties  and  consider /devise  design  alternatives  to  re¬ 
duce  the  difficulty  of  subsystem  testing. 

Justification  of  the  BIT  designer’s  recommendations  should  be  based  upon  the  quantitative 
data  in  the  signal  matrices. 

Neither  the  subsystem  design  team  nor  its  management  can  be  expected  to 
consider  design  features  unless  their  need  relates  to  the  achievement  of  speci¬ 
fied  performance  requirements.  Upon  completion  of  the  functional  path  defini¬ 
tion,  the  signal  matrices  will  be  expected  to  contain  a  preliminary  tabulation  of 
all  signals  which  are  system  outputs,  and  all  stimuli  upon  which  they  depend, 
with  the  initial  costs  of  implementation .  This  permits  the  designer  to  make 
quantitative  comparisons  between  the  Effectiveness  and  Mean  Corrective  Main¬ 
tenance  Time  required  by  the  specification,  and  such  preliminary  data  as: 

•  the  number  of  system  output  signals  which  are  likely  to  ultimately  exist, 
versus  the  number  which  are  likely  to  be  tested. 

•  the  number  of  secondary  output  signals  required  for  fault  isolation 

* 

•  the  degree  to  which  every  output  to  be  tested  is  furnished  with  test 
stimuli . 

4.3.2  Updated  Level  I  Functional  Flow  Block  Diagram  (Step  2A) 

It  is  now  necessary  to  further  develop  the  Level  I  diagram  to  identify  and 
name  each  functional  path.  Figure  4-5  depicts  such  an  updated  Level  I  diagram 
and  would  be  simply  a  more  granular  configuration  of  the  preliminary  version 
shown  in  Fig.  4-2.  Using  the  updated  diagram  and  signal  matrices  to  identify 
the  signal  paths: 
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• •  every  function  may  be  traced  from  input  to  output 

•  the  functional  paths  are  identified  by  numbers  that  are  assigned  to 
each  function  and  its  associated  path 

•  the  elements  of  the  subsystem  appear  in  more  or  less  final  configuration. 
This  means  that  the  functions  have  been  collected  into  LRUs,  and  these 
functions  will  be  implemented  in  either  hardware  or  software.  The 
term  "element,"  used  here  denotes  a  subsystem  entity  which  processes 
throughput . 

At  this  point  in  the  analysis,  two  new  items  are  introduced  into  the  infor¬ 
mation  depicted  by  the  Level  I  block  diagram. 

( 1)  Test  Functions  and  Test  Elements:  The  subsystem  being  designed 
has,  as  explained  earlier,  a  "TEST"  mode.  Any  elements  which 
are  present  in  the  system  and  have  TEST  functions  must  therefore 
be  shown  on  the  diagram  or  else  the  diagram  would  not  depict  the 
complete  system.  This  means  that  tentative  PM  and  BIT  functions 
will  be  shown  in  their  proper  places  within  each  subsystem  LRU . 

If  the  subsystem  design  concept  calls  out  AGE ,  then  the  AGE  is 
also  shown  on  the  Level  I  diagram,  because  it  is  part  of  the  sub¬ 
system  . 

(2)  Software  Elements:  Software  processes  subsystem  throughput  in 
the  same  sense  as  the  subsystem  hardware,  and  is  therefore  by 
definition,  an  element.  Major  software  programs  that  implement 
subsystem  functions  are  thus  included  in  the  Level  I  diagram,  and 
are  shown  as  parts  of  their  respective  functional  paths.  The 
rationale  for  this  is: 

•  software  is  as  much  a  part  of  a  digital  subsystem  as  its  hard¬ 
ware,  and  software  failure  can  be  a  significant  subsystem  main¬ 
tenance  and  operational  problem 

•  BIT  may  at  times  be  implemented  with  software  rather  than  hard¬ 
ware,  that  is,  as  diagnostic  programs. 
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The  main  reason  for  this  requirement  to  show  software  on  the 
Level  I  diagram  is  that  a  complete  overview  of  the  subsystem 
makes  this  approach  a  logical  necessity. 

4.3.3  Preparation  of  Level  II  Functional  Flow  Block  Diagrams  (Step  2B) 

Each  functional  path  of  the  subsystem  will  now  be  the  subject  of  its  own 
Level  II  Functional  Flow  Block  Diagram.  These  diagrams  will  depict  each  of  the 
functional  paths  in  more  detail ,  and  each  function  will  be  shown  in  terms  of  the 
signal! s)  which  implement  its  outputs.  Figure  4-6  illustrates  a  functional  path 
from  the  hypothetical  radar.  Note  that  both  input  and  output  signal  numbers 
appear  on  the  diagram,  including  test  stimulus  signals.  Also,  note  that  the  in¬ 
ternal  elements  of  the  subsystem  LRUs  which  contribute  to  this  functional  path 
are  shown  in  abbreviated  form  such  as  partial  circuit  or  logic  diagrams ,  or  as 
LRU  internal  block  diagrams. 

The  Level  II  diagrams  complete  the  chain  of  logically  organized  technical 
subsystem  descriptions  required  for  analysis.  The  continuity  of  information 
extends  from  the  system  specification  and  its  requirements  to  each  input  and 
output  signal  of  every  functional  path,  and  includes  all  test  elements  and  all 
software  elements.  Every  feature  of  the  subsystem  has  been  described  in  a 
unified  and  interrelated  manner  which  may  be  used  to  indicate  two  critical  BIT 
design  considerations: 

•  what  subsystem  responses  must  be  considered  for  testing 

•  what  stimuli  are  required  to  achieve  these  tests. 

There  is  now  an  organized  and  well  defined  set  of  technical  decisions  to  be 
made  by  the  BIT  designer,  and  he  has  a  set  of  documentation  that  will  assist  him 
in  ensuring  complete  analysis  of  the  subsystem. 

4.3.4  Updating  of  Signal  Matrices  (Step  2C) 

At  this  time  the  designer  can  use  the  detailed  information  developed  on  the 
Level  II  diagrams  to  review  the  signal  matrices,  add  new  information,  and 
modify  initial  data.  This  will  bring  the  signal  matrices  to  a  stage  of  completion 
commensurate  with  the  degree  to  which  the  subsystem  design  has  evolved.  From 
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the  analysis  which  was  necessary  to  prepare  the  Level  II  diagrams ,  it  is  likely 
that  there  will  be  additional  primary  or  secondary  output  signals  to  be  added 
to  the  matrices,  along  with  their  defined  stimulus  requirements. 

The  BIT  designer  will  then  be  in  a  position  to  review  both  matrices  and 
ensure  that  the  signal  parameters  are  updated  for  every  mode  of  system  opera¬ 
tion.  A  design  review  by  all  members  of  the  team  is  recommended  at  this  point, 
to  be  certain  that  the  information  is  as  accurate  and  complete  as  possible,  con¬ 
sistent  with  the  degree  to  which  subsystem  design  is  complete. 

Those  columns  of  the  output  matrix  which  define  test  strategy  now  present 
the  designer  with  a  detailed  set  of  technical  data  to  permit  preliminary  decisions 
as  to  which  signals  will  have  to  be  tested.  Once  these  columns  have  been  filled 
with  initial  entries ,  the  designer  will  be  able  to  make  a  first  estimate  of  the  de¬ 
tection  percentages  which  would  result  from  this  set  of  decisions .  In  summary , 
the  appropriate  columns  will  identify: 

•  the  numbers  of  signals  that  exist 

•  the  numbers  that  are  tentatively  to  be  tested 

•  the  types  of  signals  involved,  and  tneir  electrical  ranges 

•  the  numbers  of  stimuli  required  for  the  signals  to  be  tested,  and  where 
these  stimuli  will  be  obtained 

•  initial  estmates  of  BIT  cost,  assuming  that  the  design  has  reached  a 
stage  where  the  cost  columns  are  filled. 

At  this  point,  care  should  be  taken  to  be  certain  that  every  signal  which 
must  be  tested  has  corresponding  stimuli  available,  either  from  the  system  if 
tested  in  an  active  mode,  or  from  a  special  test  mode  source. 

4.4  DEVELOPMENT  OF  THE  PM/BIT  DESIGN  CONCEPT  (STEP  3) 

At  this  stage  of  subsystem  development,  one  or  more  design  concepts  will 
have  been  defined  in  sufficient  detail  to  allow  the  development  of  corollary  PM/ 
BIT  design  concepts.  Based  upon  the  subsystem  concepts,  and  the  signal  ma¬ 
trices  and  diagrams  produced  by  Steps  (1)  and  (2)  of  this  methodology,  the 
PM /BIT  design  concepts  can  now  be  generated. 


A  PM  /BIT  design  concept  consists  of  the  key  hardware  and  software  fea¬ 
tures  of  a  PM /BIT  implementation  which  are  compatible  with  the  evolving  subsys¬ 
tem  maintenance  concept  and/or  maintenance  plan.  It  must  also  meet  the  Effec¬ 
tiveness  and  Mean  Test  Time  parameters  required  by  the  subsystem  specifica¬ 
tion. 

A  design  concept  details  and  interrelates  the  following  key  PM/BIT  design 
features  that  are  to  be  intrinsic  parts  of  its  related  subsystem  design  concept: 

•  signals  measured,  by  mode 

•  stimuli  required,  by  mode 

•  nominal  and  tolerance  values,  by  mode 

•  sensor  types  and  locations 

•  signal  conditioner  types  and  locations 

•  location  and  processing  capability  of  PM /BIT  evaluator  function(s) 

•  format  of  PM /BIT  information  between  sensors  and  evaluators 

•  display  devices  and  display  formats 

•  PM /BIT  architecture  (viz. ,  the  overall  scheme  for  interconnecting 
sensor,  evaluation,  and  display  elements) 

•  the  estimated  cost  of  the  PM /BIT  configuration,  as  the  summation  of 
costs  of  the  above. 

The  procedure  for  developing  a  PM /BIT  design  concept  is  summarized  as 
consisting  of  the  following  seven  sub-steps: 

(1)  Review  the  preliminary  subsystem  maintenance  concept  and/or 
maintenance  plan  and  develop  a  complete  understanding  of  how  the 
subsystem  is  to  be  used  and  maintained. 

(2)  Make  initial  decisions  as  to  signals  to  be  tested  by  PM/BIT,  and  de¬ 
fine  the  types  of  sensors  and  signal  conditioners  required  and  their 
estimated  costs.  Record  these  data  in  the  signal  matrices. 
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(3)  Choose  a  candidate  PM /BIT  architecture  that  integrates  the  above 
devices  with  the  evaluator  capability.  The  evaluator  capability 
may  be  either  centralized  or  distributed,  depending  on  the  overall 
subsystem  architecture.  Estimate  the  costs  of  the  evaluator  capa¬ 
bility  . 

(4)  From  the  data  in  the  signal  matrices,  compute  an  initial  estimate  of 
PM /BIT  effectiveness. 

(5)  From  the  data  in  the  signal  matrices,  compute  an  initial  estimate  of 
subsystem  mean  test  time. 

(6)  Take  the  sum  of  the  above  estim  ited  cost  factors. 

(7)  Compare  estimated  effectiveness,  mean  test  time,  and  costs  with 
the  like  parameters  of  the  subsystem  design  control  specification, 
and  adjust  the  design  concept  to  the  point  where  these  estimates 
and  the  specifications  agree  to  within  approximately  10%. 

If  repeated  adjustments  to  the  PM /BIT  design  concept  do  not  produce  suffi¬ 
cient  agreement  with  the  costs,  effectiveness,  and  mean  test  times  set  forth  in 
the  subsystem  design  control  specification,  then  it  may  be  that: 

•  the  specified  values  are  not  realistic;  in  this  case,  the  PM /BIT  designer 
must  recommend  changes,  and  justify  these  on  the  basis  of  data  and 
analyses  to  date 

•  the  overall  subsystem  design  concept  may  be  excessively  difficult  or 
costly  to  test,  and  the  data  and  analyses  to  date  will  support  this  con¬ 
clusion;  testability  improvements  will  be  required,  or  an  alternate  de¬ 
sign  concept  may  afford  improved  testability. 

The  two  most  fundamental  determinant-  of  PM /BIT  effectiveness  are  the 
numbers  and  locations  of  signals  measured,  and  the  quality  of  these  measure¬ 
ments.  The  numbers  and  kinds  of  signals  measured  determine  the  degree  to 
which  faults  may  be  detected  and  isolated  by  PM/BIT.  The  quality  with  which 
these  signals  are  measured  determine  the  degree  to  which  the  information  avail¬ 
able  from  the  signals  s  actually  realized.  Small  changes  in  either  of  these 
fundamentals  often  have  a  very  significant  effect  on  PM /BIT  effectiveness,  and 
the  significance  of  these  changes  is  more  pronounced  as  subsystem  complexity 


increases. 


4.4.1  Design  Guidelines 

PM/ BIT  tolerances  should  be  set  to  values  appropriate  for  maintenance  testing,  not 
necessarily  the  same  as  those  used  for  purposes  of  qualification  and  acceptance  test. 

Field  maintenance  personnel  and  subsystem  operators  apply  the  terms 
"fault,"  "failure,"  or  "malfunction"  to  any  case  where  a  system  is  observed  to 
perform  less  than  adequately  oy  its  operator.  The  classic  engineering  definitions 
in  terms  of  nominal  values  and  tolerances  are  used  for  design,  qualification,  and 
acceptance,  but  do  not  necessarily  apply  in  the  context  of  field  maintenance. 
Moreover,  tolerances  used  for  qualification  and  acceptance  do  not  necessarily 
represent  optimal  tolerances  for  field  operation. 

In  d  .er mining,  which  primary  output  signals  are  to  be  tested,  the  object  is  to  satisfy  any  per¬ 
formance  monitoring  requirement,  and  be  certain  that  an  ample  capability  to  detect  faults  exists 
for  purposes  of  maintenance  effectiveness. 

Performance  monitoring  capability  is  not  "optional."  It  is  a  requirement  be¬ 
cause  the  subsystem  operator  needs  to  know  system  status  for  reasons  of  safety 
or  mission  effectiveness.  Beyond  the  PM  requirement,  it  will  be  necessary  to  de¬ 
tect  a  subset  of  failure  modes  sufficient  to  meet  the  effectiveness  requirement. 

Do  not  expect  PM/ BIT  functions  which  monitor  primary  output  signals  to  produce  fault  iso¬ 
lation  information.  The  purpose  of  these  functions  is  to  detect,  not  to  isolate. 

Primary  output  signals  are  always  monitored  at  the  output  nodes  of  a  func¬ 
tional  path,  because  that  is  the  only  location  which  can  logically  confirm  function¬ 
al  path  integrity.  From  information  theory,  it  can  be  shown  that  these  locations 
produce  minimal  fault  isolation  information.  Two  distinct  types  of  information 
are  produced:  1)  functional  path  status,  that  is,  information  whicn  shows  a  path 
to  be  "food"  or  "bad";  and,  2)  fault  isolation  information,  that  is,  information 
as  to  where  a  fault  is  located  along  a  functional  path.  Primary  Output  Signals 
produce  only  the  former  (status)  information. 

I)<>  not  expect  BIT  functions  that  monitor  secondary  output  signals  to  piudnce  fault  detection 
information.  Their  purpose  is  to  isolate  known  faults,  not  to  detect  faults. 

A  test  point  that  provides  maximum  fault  isolation  information  will  inherently 
provide  only  about  50%  confidence  that  a  fault  within  its  tested  group  of  elements 
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will  be  detected.  Thus,  the  further  away  from  an  output  node,  the  poorer  the 
fault  detection  capability.  The  purpose  of  secondary  output  sensors  is  to  enable 
fault  isolation,  and  this  intrinsically  makes  them  less  than  optimal  for  detection. 

Design  the  PM/BIT  evaluator  function  to  make  thorough  use  of  all  available  fault  detection 
and  fault  isolation  information. 

Many  of  the  PM /BIT  designs  reviewed  suffer  from  too  narrow  a  definition 
of  information  to  be  evaluated.  The  designer  should  at  least  consider  providing 
a  capability  to  include  the  following  kinds  of  information  in  the  PM /BIT  evaluation 
process : 

•  Evaluate  the  pattern  of  signals  which  fail;  this  will  produce  more  useful 
results  than  just  designing  PM /BIT  to  look  at  signals  or  functions  on  a 
"one-by-one"  basis 

•  evaluate  the  sequence  in  which  signals  fail;  a  given  pattern  of  signal 
failure  may  imply  different  failure  modes,  depending  upon  the  temporal 
order  of  signal  fai’ure 

•  evaluate  related  (non-signal)  information ;  most  subsystem  failures  are 
accompanied  by  operator  perceptions.  For  example,  subsystems  often 
incorporate  meters ,  displays ,  numerical  readouts ,  fuse  indicator  lights , 
power  indicator  lights ,  and  other  devices  which  provide  information  to 
the  operator  or  maintenance  technician,  but  these  devices  are  not  part  of 
PM /BIT  in  any  formal  sense.  However,  it  would  be  a  mistake  to  ignore 
such  an  obvious  datum  as  a  tripped  circuit  breaker  in  deciding  the  main¬ 
tenance  action  to  be  taken  for  a  given  BIT  failure  pattern 

•  evaluate  relat  d  subsystems'  PM /BIT  indications;  these  may  provide  an 
indication  that  inputs  to  the  subsystem  of  interest  are  missing  or  out  of 
tolerance;  obviously,  such  information  would  have  to  be  taken  into  ac¬ 
count  in  determining  the  subsequent  maintenance  actions. 

Before  implementing  PM/BIT  to  monitor,  evaluate,  and  display  a  signal's  status,  check  to  see 
if  that  capability  is  not  already  inherent  in  the  subsystem,  or  in  a  related  subsystem. 

Historically,  the  earliest  implementations  of  PM /BIT  occurred  after  the  fact, 
by  using  existing  subsystem  circuits  and  indicators  to  add  a  new  PM /BIT  func- 
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tion.  These  implementations  were  very  cost  effective  because  they  did  not  add 
new  hardware  to  achieve  the  PM /BIT  capability.  Since  the  BIT  designer  is  con¬ 
strained  to  achieve  the  required  effectiveness  and  mean  corrective  maintenance 
time  within  the  specified  cost  envelope ,  this  guideline  offers  the  chance  that 
some  such  capability  will  have  no  cost  at  all  (i.e. ,  no  cost  assignable  to  his 
BIT).  This  would  allow  the  designer  to  assign  his  fiscal  resources  to  the  goal 
of  increasing  fault  detection /isolation  capability  in  subsystem  areas  which  lack 
such  intrinsic  possibilities. 

Experience  indicates  that  many  of  the  most  severe  problems  encountered  in  electronic  sub¬ 
system  maintenance  arise  from  intermittent  failures,  bent  connector  pins,  open  or  shorted  cable 
conductors,  etc.  The  BIT  designer  should  not  ignore  these  issues.  He  should  familiarize  himself  with 
these  issues,  and  configure  his  PM/BIT  design  to  minimize  their  impact. 

Study  research  has  shown  that  the  above  issues  overshadow  the  more  con¬ 
ventional  requirement  to  merely  detect  and  isolate  catastrophic  failures ,  while 
at  the  same  time,  PM/BIT  designs  make  little  or  no  attempt  to  address  these  mat¬ 
ters.  PM/BIT  offers  some  potential  for  very  significant  reduction  of  these  main¬ 
tenance  problems.  Any  solutions,  however  partial,  would  be  of  major  significance. 
Appendix  D  to  this  report  contains  technical  discussions  of  "False  Alarms"  and 
"Intermittents , "  and  the  relationship  between  these  phenomena. 

Feedback  loops  present  inherent  testability  problems  for  PM/BIT  or  any  other  test  subsystem. 
Special  testability  design  features  must  be  provided  to  permit  adequate  fault  detection  and  isolation. 

In  general,  feedback  loops  have  the  inherent  property  of  continued  func¬ 
tion  when  internal  elements  are  marginal.  Often,  operation  at  limit  conditions, 
or  outright  catastrophic  failure,  is  a  prerequisite  for  loop  faults  to  be  detectable. 
Historically,  these  properties  of  feedback  loops  present  significant  testing  diffi¬ 
culties  to  any  method  of  test.  PM/BIT  testing  is  no  exception  in  this  respect. 

There  are  three  design  tactics  for  making  feedback  loops  testable  by 
PM/BIT: 

( 1)  When  the  feedback  element  is  much  more  reliable  than  the 

forward  element  of  a  loop  (i.e.,  20  times  or  more),  it  can  be  made 
part  of  an  acceptable  ambiguity  in  isolation,  since  statistically 
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derived  T.O.  instructions  to  remove  the  least  reliable  element 
would  be  incorrect  for  only  one  out  of  20  failures. 

(2)  The  forward  and  feedback  elements  of  the  loop  can  be  combined  into 
the  same  LRU,  to  obviate  fault  isolation  ambiguity. 

(3)  The  feedback  path  can  be  provided  with  special  testability  design 
features . 

The  first  of  the  above  alternatives  is  not  really  a  solution,  because  it  is 
simply  a  judgment  that  the  issue  is  not  significant  in  a  given  case.  The  second 
alternative  is  an  architectural  solution  which  may  or  may  not  apply  to  a  given  de¬ 
sign  case.  The  third  alternative,  incorporation  of  special  testability  design 
features,  is  the  only  really  viable  approach  to  the  issue.  The  choice  of  test¬ 
ability.  features  will  depend  upon  the  specific  design  of  the  loop  being  con¬ 
sidered.  Some  potential  features  which  should  be  considered  include: 

•  Dynamic  Modeling  -  When  there  is  adequate  computer  memory  and 
processing  capacity,  it  may  be  feasible  to  model  the  feedback  loop 
dynamically,  and  compare  actual  outputs  with  modeled  outputs  for 
the  same  inputs.  This  would  require  that  both  the  input  and  output 
of  the  loop  be  accessible  for  test  purposes 

•  Voting  Redundant  Elements  -  Certain  designs  will  yield  to  the  use  of 
redundant  elements,  and  voting  of  their  outputs  to  select  (for  example) 
the  best  two  identical  outputs  of  three  elements.  This  may  be  useful 
where  loop  inputs  are  inaccessible  and  redundant  elements  are  inex¬ 
pensive,  such  as  in  the  sensors  of  a  flight  control  system 

•  Test  Loops  When  Quiescent  -  In  some  cases ,  particularly  analog  control 
systems ,  the  feedback  element  may  be  quiescent  for  long  periods  of 
time.  A  low  level  test  signal  with  a  mean  value  of  zero  could  be  used 
to  test  the  feedback  element  at  such  times .  If  the  chosen  signal  is 
within  the  passband  of  the  element  under  test,  but  outside  the  pass- 
band  of  the  loop ,  it  may  even  be  possible  to  use  this  approach  when  the 
loop  is  active 
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•  Provide  Localized  Tests  Within  a  Loop  -  Digital  parity  checks ,  check¬ 
sum  tests,  or  "echo-back"  of  digital  data  are  examples  of  localized 
tests  that  may  be  built  into  the  active  functions  of  a  loop 

•  Provide  Means  for  Opening  the  Loop  -  This  is  the  only  design  tactic 
which  will  always  result  in  a  valid  ability  to  test  the  elements  of  a 
feedback  loop.  However,  it  must  be  used  during  periods  of  loop 
quiescency.  Additionally,  in  using  this  approach  for  safety- related 
systems  (such  as  flight  controls),  absolutely  fail-safe  design  is 
required  to  ensure  that  the  loop  will  not  be  driven  to  the  open 
condition  by  a  PM /BIT  failure. 

4.4.2  Subsystem  Maintenance  Concept /Maintenance  Plan  Review  (Step  3A) 

Information  from  the  subsystem  maintenance  concept  and  maintenance  plan 
defines  the  environment  in  which  the  PM /BIT  must  function.  To  ensure  that 
the  designer  is  fully  cognizant  of  such  issues ,  he  should  obtain  copies  of  these 
documents  at  their  current  stages  of  completion,  and  study  them  to  ascertain 
the  following  logistic  and  technical  constraints: 

•  what  will  be  the  designated  levels  of  maintenance,  and  what  tasks 
will  be  carried  out  at  each? 

•  what  personnel  skills  and  skill  levels  will  typify  the  maintenance 
personnel  who  are  to  maintain  his  subsystem? 

•  what  training  courses  are  these  maintenance  personnel  expected 
to  have  completed? 

•  what  is  the  policy  with  respect  to  spares  locations,  quantities,  re¬ 
supply  times,  etc.? 

•  what  will  be  the  types  and  quantities  of  technical  orders  provided  to 
guide  maintenance  personnel  in  maintaining  the  subsystem,  and 

what  will  be  their  contents  with  respect  to  the  employment  of  PM/BIT? 

•  what  maintenance  management  procedures  will  guide  the  above 
subsystem  maintenance,  and  what  maintenance  data  will  be  recorded 
to  describe  the  effectiveness  of  PM /BIT? 
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•  what  organizational  and  intermediate  maintenance  level  AGE  is 
specified  for  maintenance  of  his  subsystem ,  and  what  are  its 
characteristics  and  capabilities?  How  are  the  signals  and  tolerances 
measured  by  this  AGE  determined? 

It  must  be  understood  that  the  maintenance  concept  and/or  maintenance 
plan  are  often  preliminary  at  this  stage  of  subsystem  design.  However,  DoD 
acquisition  procedures  require  that  they  exist.  To  some  degree,  the  designer 
is  expected  to  consult  with  systems  engineering  personnel  preparing  these  docu¬ 
ments  ,  to  not  only  obtain  their  inputs  to  his  design  requirements ,  but  also  to 
provide  them  with  technical  information  as  to  the  design  features  and  capabili¬ 
ties  of  the  subsystem  he  is  designing.  This  is  intended  to  be  a  two-way  process 

•  the  subsystem  must  be  designed  to  function  with  the  resources  and 
procedures  called  out  in  the  maintenance  plan,  but  also, 

•  the  resources  and  procedures  must  be  determined  on  the  basis 
of  the  subsystem  design  concept. 

4.4.3  Initial  Determination  of  Output  Signals  To  Be  Measured  (Step  3B) 

A  specific  list  of  primary  and  secondary  output  signals  to  be  measured 
should  be  designated  and  recorded  in  the  signal  matrices.  The  goal  is  to  ap¬ 
proximate  PM /BIT  effectiveness,  mean  test  time,  and  cost  envelope  parameters 
given  in  the  design  control  specification.  Optimization  will  take  place  in  subse 
quent  steps  of  the  methodology. 

There  are  three  considerations  which  lead  to  the  choice  of  these  signals,  in 
the  following  order  of  priority: 

1)  Performance  Monitoring  Requirements  -  The  functions  requiring  PM  are 
given  in  the  subsystem  design  control  specification.  These  requirements 
stem  from  reasons  of  operational  necessity,  safety,  or  mission  essential¬ 
ity,  and  are  of  mandatory  first  priority. 

2)  BIT  Fault  Detection  -  Primary  output  signals  not  measured  for  perfor¬ 
mance  monitoring  are  candidates  for  BIT  fault  detection.  These  will  be 
selected  by  criteria  of  signal  failure  rate,  measurement  quality,  and  cost 
of  measurement. 


3)  BIT  Fault  Isolation  -  The  secondary  output  signals  along  each  path 
leading  to  a  primary  output  signal  are  candidate  locations  for  BIT  fault 
isolation  measurement ,  but  only  if  the  primary  output  signal  is  one  which 
is  to  be  measured.  The  numbers  and  locations  of  secondary  output  sig¬ 
nals  to  be  measured  are  determined  by  criteria  of  fault  isolation  informa¬ 
tion  produced,  measurement  quality,  and  cost  of  measurement. 

The  following  discussions  provide  recommended  procedures  for  use  in  desig¬ 
nating  signms  to  be  measured,  by  class. 

4.4. 3.1  Signals  Requiring  Performance  Monitoring  -  The  primary  output  signals 
of  each  function  designated  for  PM  by  the  subsystem  design  control  specifica¬ 
tion  must  be  designated  for  measurement.  The  signals  and/or  stimuli  which 
these  outputs  are  contingent  upon  must  also  be  designated  as  required  in  the  ap¬ 
propriate  mode: 

•  there  must  be  stimuli  present  in  the  operational  modes,  to  provide 
operator  information  as  to  function  status 

•  If  the  subsystem  is  partly  quiescent  during  maintenance,  it  may  also  be 
necessary  to  provide  alternate  stimuli  to  support  testing  (this  would  be 
a  frequent  requirement  with  certain  classes  of  avionic  subsystems) . 

At  this  time,  the  BIT  designer  should  review  the  subsystem  diagrams  and 
signal  matrices,  designate  the  PM  signals  and  stimuli,  and  complete  the  costs, 
quality  factor,  and  time  factor  entries  in  the  matrices.  Also,  an  initial  failure 
rate  should  be  estimated  and  entered  for  each  of  these  signals. 

4. 4. 3. 2  Initial  Designation  of  Signals  Measured  for  Bit  Fault  Detection  -  It  can 
be  shown  that  an  undetected  failure  results  in  a  maintenance  uncertainty  ap¬ 
proximately  equal  to  the  number  of  LRUs  in  the  subsystem.  That  is,  when  a 
maintenance  technician  is  faced  with  failure  symptoms  undetected  by  BIT,  he 
will  tend  to  sequentially  replace  LRUs  until  the  symptoms  are  no  longer  apparent 
For  this  reason,  the  designer  should  initially  designate  all  remaining  primary 
output  signals  for  BIT  fault  detection  measurement  (i.e.  ,  those  which  have  not 
been  designated  for  PM). 

In  many  cases  this  approach  will  not  yield  a  BIT  design  within  the  cost  en¬ 
velope  specified  for  BIT.  Later  steps  in  this  methodology  therefore  describe  a 


technique  for  eliminating  the  least  cost  effective  of  these  measurements,  in  the 
form  of  a  trade-off  based  upon  signal  failure  rate,  measurement  quality  factor, 
and  production  cost  of  the  measuring  capability: 

•  Failure  rate  -  is  a  measure  of  the  fault  detection  information  theoretically 
available  when  a  given  signal  is  measured.  The  more  often  the  path 
leading  to  a  signal  output  fails  the  more  information  obtained  by  testing 
that  signal 

•  Quality  factor  -  is  the  designer's  estimate  of  the  percent  of  the  mea¬ 
surements  of  a  signal  that  reach  a  correct  go /no-go  conclusion 

•  Cost  factor  -  is  the  designer's  estimate  of  the  costs  of  implementing  the 
chosen  sensor /signal  conditioner.  It  is  employed  to  measure  the  worth 
of  detecting  a  failure. 

The  trade-off  will  take  the  general  form  of  ranking  BIT  fault  detection  mea¬ 
surements  in  terms  of  their  worth ,  and  eliminating  those  which  have  the  least 
worth,  according  to  the  algorithm: 

F  xQ, 

W„  =  rp  f  (Eq-  31) 

d  C 

P 

where  is  the  worth  of  each  primary  output  signal  to  be  measured,  F  is  the 

failure  rate  of  the  path  leading  to  that  primary  output ,  Q ^  is  the  measurement 

quality  factor  as  a  percentage  of  unity  and  C  is  the  estimated  cost  of  the  PM /BIT 

P 

capability  to  measure  that  signal. 

In  ranking  the  primary  output  signals ,  the  costs  used  must  include  those 
of  generating  related  stimuli  whenever  these  stimuli  are  not  normally  present 
in  the  test  mode.  In  the  general  case,  for  avionics,  it  is  relatively  common  for 
contingent  signals  to  be  absent  during  ground  testing,  so  that  BIT  requires 
special  stimuli  to  be  generated.  For  ground  electronic  subsystems,  the  neces¬ 
sary  stimuli  are  usually  available,  making  BIT  cost  less.  In  both  cases,  how¬ 
ever,  it  is  necessary  to  show  that  any  stimuli,  needed  to  produce  a  signal,  will 
be  present  when  BIT  measures  that  signal,  and  to  account  for  its  costs  in  the 

C  term  of  the  trade-off. 

P 
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For  those  signals  which  have  intrinsic  fault  detection  capability,  is  in¬ 
determinate  because  is  zero  insofar  as  the  trade-off.  In  ranking  these  par¬ 
ticular  signals  for  fault  detection  worth,  they  are  assigned  the  greatest  figure 
of  merit. 

4. 4. 3. 3  Initial  Designation  of  Signals  For  Fault  Isolation  -  When  a  primary  out¬ 
put  signal  failure  is  detected,  and  there  is  no  fault  isolation  capability,  mainte¬ 
nance  uncertainty  is  approximately  equal  to  the  number  of  LRUs  in  the  path  lead¬ 
ing  to  that  signal.  Maintenance  personnel  will  tend  to  sequentially  replace  these 
LRUs  in  order  of  failure  probability  until  the  failure  symptoms  are  no  longer  ap¬ 
parent  . 

Initially,  the  BIT  designer  should  designate  enough  fault  isolation  sensors 
to  isolate  every  primary  output  signal  failure  to  the  LRU.  Here  again,  this  will 
tend  to  produce  an  "ideal"  capability  with  costs  in  excess  of  those  allowed  by 
the  cost  envelope.  The  subsequent  trade-offs  will  eliminate  the  least  cost  ef¬ 
fective  of  these  sensors. 

Fault  isolation  sensors  resolve  uncertainty  as  to  the  location  of  faults  de¬ 
tected  by  fault  detection  sensors.  Each  fault  isolation  sensor  divides  its  func¬ 
tional  path  into  two  sub-paths ,  one  containing  the  fault  and  the  other  known  not 
to  contain  the  fault.  The  sensor  wnich  resolves  the  greatest  uncertainty  as  to 
fault  location  therefore  offers  the  most  fault  isolation  capability. 

Information  theory  states  that,  given  a  fault,  the  uncertainty  resolved  as 
to  its  location  when  a  sensor  makes  a  test  is  equal  to  the  summation,  over  all 
elements  of  the  tested  path,  of  the  probabilities  that  the  fault  is  between  the  in¬ 
put  and  the  sensor,  multiplied  by  Log2  of  this  probability.  The  universal  solu¬ 
tion  of  this  function  is  plotted  graphically  in  Fig.  4-7,  where: 

•  the  vertical  axis  shows  relative  uncertainty  resolved  on  a  scale  of 
zero  (none)  to  unity  (all  possible) 

•  the  horizontal  axis  shows  the  probability  (P^.)  that  the  fault  lies  between 
the  input  and  the  sensor. 
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Fig.  4-7  Amount  of  Uncertainty  Resolved  bv  a  Sensor 


It  will  be  noted  that  =  0.5  is  the  optimal  sensor  location.  This  is  the  so- 
called  "half-split"  well  known  to  test  designers.  It  will  also  be  noted  that  the 
uncertainty  resolved  decreases  to  zero  as  the  sensor  is  located  at  either  end  of 
the  path.  To  determine  the  uncertainty  resolved  by  a  given  sensor  location,  it 
is  only  necessary  to  determine  Pf,  then  refer  to  the  graph  to  obtain  its  argument 
(that  is,  to  obtain  the  relative  amount  of  uncertainty  which  may  be  resolved  by 
the  sensor  at  Pp . 

For  all  the  sensors  on  a  path,  the  P^  values  may  be  rapidly  determined  by 
the  following  process: 

•  since  it  is  given  that  the  path  has  failed,  Pf  for  the  total  path  equals 
unity 

•  the  relative  failure  probability  of  any  element  in  the  path  is  in  direct 
arithmetic  proportion  to  its  failure  rate 

•  therefore,  normalize  the  elemental  failure  rates  such  that  their  sum 
equals  unity 


•  take  the  sum  of  each  normalized  value  between  the  input  to  the  path 
and  the  sensor  location,  and  this  is  the  value  of  P^,  for  that  sensor. 

Refer  to  the  graph  and  obtain  Uf  as  the  argument  of  P^.. 

The  worth  of  each  fault  isolation  sensor  is  then  computed  in  terms  of  the 
uncertainty  resolved  at  its  location ,  the  quality  with  which  it  measures  the  re¬ 
lated  signal,  and  the  cost  of  implementation  by  the  following: 

w.  =  Uf  X  Qf  (Eq.  32) 

1  C 

P 

with  the  same  definition  of  terms  used  in  calculating  the  worth  of  fault  detection 

sensors,  except  that  U.  replaces  F 

x  rp 

By  the  above  process,  the  BIT  designer  may  readily  list  all  the  fault  isola¬ 
tion  sensors  in  their  relative  order  of  worth.  Having  completed  that  process,  he 
should  be  certain  that  the  related  entries  are  made  and/or  updated  in  the  signal 
matrices . 

4.4.4  Development  of  a  PM  /BIT  Architecture  (Step  3C) 

Having  initially  designated  sensor  locations ,  the  next  step  in  formulating  a 
PM/BIT  design  concept  will  be  the  choice  of  an  architecture.  The  fundamental 
issue  is  the  degree  to  which  measurement,  signal  conditioning,  and  evaluation 
are  to  be  centralized  or  decentralized.  Most  literature  researched  by  the  study 
deals  with  the  boundaries  of  this  issue  and  is  briefly  summarized  as  follows. 

•  Centralization  is  the  only  alternative  which  permits  deductive  use  of 
all  the  information  obtained  from  the  sensors  by  analysis  of  fault  pat¬ 
terns  rather  than  isolated  faults.  This  implies  the  use  of  a  processor 
(computer),  either  in  the  subsystem,  at  the  system  level,  or  both.  On 
the  other  hand,  computer  failure  renders  the  PM /BIT  capability  useless. 

•  Decentralization  makes  it  simple,  straightforward,  and  reliable  to  evalu¬ 
ate  each  signal  at  its  sensor  location.  When  a  given  sensor,  signal  con¬ 
ditioner,  or  measurement  circuit  fails,  the  remaining  PM /BIT  capability 
is  relatively  unimpaired.  On  the  other  hand,  total  decentralization  makes 
it  impossible  to  evaluate  failure  patterns /signatures,  and  would  appear  to 


preclude  the  high  degree  of  PM /BIT  effectiveness  that  must  necessarily 
be  typical  of  future  subsystem  designs. 

Between  these  two  boundaries,  there  exist  various  degrees  of  centralization 
and  decentralization.  The  choice  of  some  set  of  hierarchical  levels  for  compari¬ 
son  and  evaluation  depends  fundamentally  on  the  architectur  ■>  of  the  subsystem 
itself.  The  designer  should  therefore  review  the  Level  I  Functional  Flow  Block 
Diagram  and  the  subsystem  design  control  specification,  and  determine  these 
levels  in  light  of  the  following  subsystem  requirements  and  characteristics: 

•  Does  the  subsystem  employ  a  data  bus?  Many  current  subsystem  de¬ 
signs  use  data  bus  concepts,  and  this  design  feature  makes  centralized 
fault  evaluation  a  more  likely  choice.  Additionally,  the  format  and 
protocols  for  a  subsystem  bus  will  define  the  format  of  the  PM /BIT  data 
as  well. 

•  Does  the  design  control  specification  define  a  system  level  evaluation 
and/or  display  function?  Some  specifications  may  require  very  high  re¬ 
liability  in  PM  detection  and  display.  This  may  leave  the  BIT  designer 
little  choice  other  than  to  perform  the  comparison  of  measured  signals 
with  limits  very  close  to  the  point  of  signal  origin ,  and  provide  a  "hard¬ 
wired"  go /no-go  discrete  from  that  point  to  a  central  master  caution  dis¬ 
play.  The  BIT  evaluation  function  will  require  these  signals  as  well,  in 
order  to  use  them  for  deductive  fault  pattern  analysis.  A  PM  configura¬ 
tion  of  this  type  would  influence  the  choice  of  a  BIT  configuration. 

In  addition  to  the  above,  many  specifications  may  define  a  system  level 
evaluation  and  display  function,  and  require  the  subsystem  PM /BIT  to  inter¬ 
face  with  this  function  for  centralized  evaluation  and  display  of  subsystem  sig¬ 
nal  status.  This  presents  an  issue  in  using  BIT  for  maintenance.  The  subsys¬ 
tem  under  design  may  require  its  own  evaluation  function  because  there  is  no 
certainty  that  the  evaluation  performed  by  an  adjacent  subsystem  will  be  opera¬ 
tive  or  available  when  needed. 

System  level  evaluation  and  display  also  implies  that  signals  from  other  sub¬ 
systems  which  provide  inputs  to  the  subsystem  at  hand  will  also  have  their  own 
BIT  or  PM  detectors.  If  this  is  the  case,  then  the  system  level  evaluator  will 
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"know"  when  an  input  to  the  subsystem  has  failed.  This  information  could  be 
acquired  by  a  local  subsystem  evaluator,  and  used  to  define  when  an  input  to 
that  subsystem  has  failed.  This  approach  would  have  obvious  advantages  in 
maintaining  that  subsystem.  For  example: 

•  when  an  input  is  missing,  the  subsystem  BIT  would  not  indicate  a  failure 

•  when  an  input  from  another  subsystem  is  "good,"  a  sensor  within  the 
subsystem  at  hand  could  make  a  second  (redundant)  measurement  to 
determine  whether  wiring  harness  failure  caused  loss  of  the  input  sig¬ 
nal,  even  though  it  was  "good"  at  the  point  of  origin. 

Either  of  the  above  possibilities  would  address  the  currently  severe  organiza¬ 
tional  level  maintenance  problems  associated  with  wiring  harness  troubles  and 
BIT  diagnostic  errors. 

To  clarify  the  above,  consider  a  radar  subsystem  that  requires  a  certain 
input  from  an  inertial  subsystem.  Assume  that  the  input  is  missing  and  the 
radar's  BIT  indicates  a  radar  malfunction.  Further  assume  that  the  inertial 
subsystem's  BIT  indicates  that  it  is  providing  that  particular  output.  Now,  if 
both  of  these  items  of  information  were  made  available  to  an  overall  system 
evaluator,  it  would  indicate  a  harness  problem. 

What  is  the  lowest  hierarchical  level  at  which  the  deductive  function  of  a 
BIT  evaluator  can  be  validly  performed?  In  order  to  evaluate  the  combinational 
and/or  sequential  implications  of  fault  patterns,  the  evaluator  must  capture  the 
measurement  indicatior~  from  the  signals  which  comprise  these  patterns.  Hence, 
the  answer  to  this  question  defines  the  lowest  level  at  which  evaluation  can  be 
performed  fully.  It  may  be  answered  readily  from  examination  of  the  Level  I 
Functional  Flow  Block  Diagram: 

•  consider  the  functional  inter-relationships  of  the  LRUs  which  make  up 
the  subsystem  being  designed 

•  divide  the  set  of  LRUs  into  groups  that  are  heavily  interrelated  to  mem¬ 
bers  of  a  group,  but  where  gi  mps  are  relatively  autonomous,  one  from 
the  other 


•  it  would  follow  that  each  of  these  groups  could  have  its  own  evaluator, 
and  still  achieve  full  deductive  capability. 

Thus,  the  overall  subsystem  architecture  defines  the  level  at  which  evalua¬ 
tion  should  be  performed.  Evaluation  at  the  lowest  possible  level  will  minimize 
interconnections  between  LRUs  without  compromise  to  fault  isolation  capability. 

In  cases  where  the  subsystem  itself  contains  a  suitable  processor /computer , 
evaluation  would  more  than  likely  be  assigned  to  that  unit.  In  cases  where  it 
does  not,  evaluation  at  the  lowest  level,  selected  as  indicated  above,  is  recom¬ 
mended.  The  evaluator  will  then  be  either  the  computer  element  of  the  subsys¬ 
tem,  or  one  or  more  separate  local  evalu  >rs  (i.e. ,  one  for  each  autonomous 
LRU  group).  The  latter  could  be  relatively  simple  microprocessor-based  units 
with  firmware  programs. 

What  is  the  lowest  hierarchical  level  at  which  the  "thresholding"  function 
can  be  performed?  The  term  "sensors"  as  us_d  thus  far  denotes  a  device  or 
circuit  that  acquires  a  signal  to  be  measured  (that  is,  to  be  thresholded  and 
evaluated).  Both  analog  and  digital  signals  require  this  thresholding  function, 
to  determine  that  an  analog  signal  is  or  is  not  within  tolerance,  or  to  determine 
that  a  digital  signal  has  specific  Troltage  levels  indicating  true  or  false  logic 
states.  Digital  signals  may  also  require  evaluation  to  determine  whether  a  group 
of  states  are  correct  or  incorrect ,  as  would  be  the  case  with  parallel  or  serial 
word  formats. 

In  defining  the  level  of  hierarchy  at  which  signals  are  to  be  thresholded, 
the  paramount  consideration  is  one  of  accuracy  and  reliability  of  the  go /no- go 
conclusion  obtained  by  each  such  decision.  This  is  +he  "Quality"  term  in  the  sig¬ 
nal  matrices ,  and  is  simply  the  percent  of  measurements  that  correctly  reach  a 
go  or  no-go  indication  for  a  signal. 

It  can  be  shown  that  this  "Quality"  factor  is  just  as  significant  in  deter¬ 
mining  PM /BIT  effectiveness  as  was  the  choice  of  signals  to  be  measured.  Fur¬ 
thermore,  small  changes  in  the  Quality  of  measurements  will  have  relatively  sig¬ 
nificant  influence  upon  the  Effectiveness  parameter.  For  the  degrees  of  PM /BIT 
effectiveness  required  of  future  electronic  subsystems  (90  to  95%),  the  PM /BIT 
designer  has  little  choice  but  to  maximize  Quality. 


130 


The  electrical  path  between  the  origin  of  a  signal  and  its  thresholding  cir¬ 
cuit  is  exposed  to  EMI  (noise) ,  and  also  introduces  errors  due  to  distributed 
path  constants  and  connector  interfaces.  It  follows  that  these  error  sources  are 
minimized  by  locating  the  thresholding  function  as  close  to  the  point  of  a  signal 
origin  as  is  possible. 

What  are  the  requirements  for  PM /BIT  displays?  As  noted  earlier,  the  re¬ 
sults  of  PM/BIT  evaluation  may  be  displayed  by  the  subsystem,  at  the  overall 
system  level,  or  both: 

•  if  there  is  an  overall  system  level  requirement  to  display  PM /BIT  in¬ 
formation,  the  subsystem  must  be  designed  for  compatibility  with  this 
function;  either  the  "thresholded"  data,  or  the  results  of  local  evalua¬ 
tion  must  be  passed  to  the  system  in  a  compatible  format 

•  if  there  is  no  overall  system  level  display,  or  if  it  is  required  that  the 
PM /BIT  subsystem  remain  fully  operative  even  when  the  system  level 
display  is  inoperative,  then  a  local  display  function  will  be  required 

•  if  there  is  a  central  (system  level)  display,  it  may  not  be  convenient 
for  maintenance  purposes.  This  could  also  justify  a  local  display  of 
PM /BIT  information.  For  example,  many  aircraft  avionic  systems  dis¬ 
play  PM/BIT  data  in  the  cockpit  for  use  by  the  flight  crew,  but  provide 
a  more  complete  display  of  these  data  at  a  point  more  convenient  to  the 
ground  maintenance  personnel. 

What  information  formats  are  most  appropriate  from  the  threshold  function 
to  the  evaluation  function  and  to  the  display  function,  and  also,  to  and  from  the 
system  level  PM /BIT?  This  choice  will  be  apparent  in  light  of  the  subsystem  de¬ 
sign  concept  and  the  related  PM /BIT  design  concept  thus  far  derived.  In  gen¬ 
eral,  if  there  is  already  a  subsystem  and/or  system  level  data  bus,  then  this 
will  be  the  most  economical  choice  for  PM /BIT  formats  between  threshold,  evalua¬ 
tor,  and  display.  If  there  is  no  existing  bus,  then  the  designer  should  choose 
the  most  noise-immune  and  least  expensive  means  available. 

Having  reviewed  the  emerging  subsystem  design  with  respect  to  the  above 
factors,  and  having  thereby  defined  the  BIT  design  concept,  the  PM /BIT  designer 
will  now  be  able  to  update  the  Level  I  and  Level  II  diagrams  to  show  these  de- 


tails.  Likewise,  the  signal  matrices  should  once  again  be  reviewed  and  brought 
to  a  point  of  completion  appropriate  to  this  stage  of  subsystem  design. 


A  remaining  aspect  of  the  BIT  architecture  that  can  now  be  defined  is  the 
cost  of  the  thresholding,  evaluation,  and  display  devices.  Costs  of  these  func¬ 
tions  as  they  relate  to  PM  are  not  to  be  estimated.  However,  costs  of  these  func 
tions  with  respect  to  BIT  are  significant  and  may  be  initially  approximated  by 
standard  engineering  methods,  based  on: 

•  the  numbers  and  generic  types  of  sensors,  thresholding  devices,  and 
signal  conditioners 

•  the  complexity  of  the  evaluation  function,  in  terms  of  computational  and 
memory  functions ,  either  as  a  portion  of  the  subsystem  computer  re¬ 
source,  or  as  separate  BIT  evaluation  processor(s) ,  as  applicable 

•  the  types,  locations,  complexity,  etc.,  of  the  display  devices. 

4.4.5  Initial  Estimation  of  PM/BIT  Effectiveness  (Step  3D) 

In  the  earlier  conceptual  Design  Phase,  the  Effectiveness  of  PM /BIT  was  de 
fined  as  the  ratio  of  total  malfunctions  to  total  maintenance  actions,  expressed 
as: 

C  +  R 

ET  =  - - -  (Eq.  10  of  Paragraph  2.2) 

R  ,  +  C  +  R 
nd  r 

where  C  is  the  number  of  repair-in-place  adjustments,  R  ^  is  the  number  of  no¬ 
defect  removals,  and  R  i.'  the  number  of  removals  resulting  from  actual  mal¬ 
functions. 

The  Effectiveness  requirement,  E^,  as  specified  in  the  subsystem  design 
control  specification,  must  now  be  calculated  with  respect  to  the  PM/BIT  design 
concept  just  developed.  Effectiveness  may  be  calculated  from  the  data  in  the 
signal  matrices,  and  the  subsystem  functional  path  information  in  the  block  dia¬ 
grams,  by  a  mathematically  identical  pxoression  derived  as  follows: 

Total  Malfunctions  F  x  time  F 

Et= - =  -E* -  (Eq.  33) 

Total  Maintenance  Actions  MA  x  time  MA 


i 

i 

where  F  is  the  summation  of  all  failure  rates  in  the  signal  matrices  and  MA  is 
rs  6  r 

the  estimated  overall  maintenance  action  rate. 

For  purposes  of  arriving  at  an  accurate  initial  estimate  of  effectiveness,  the 
above  terms  require  further  discussion  and  explanation. 

The  failure  rate  of  the  subsystem  (F  )  is  the  sum  of  all  estimated  failure 

rs 

rates  for  its  elements,  and  includes  the  estimated  failure  rates  for  PM /BIT  cir¬ 
cuits.  By  this  definition,  PM /BIT  failure  is  classified  as  subsystem  failure,  and 
not  as  a  false  alarm,  because  such  failures  are  just  as  "real"  as  failures  of  non-BIT 
circuits. 

The  maintenance  action  rate  will  be  greater  than  the  above  failure  rate, 
because  it  is  necessary  to  approximate  the  effects  of  undetected  faults  (UF),  BIT 
diagnostic  errors  (BDE),  and  ambiguity  errors  (BA).  Since  all  faults  must  either 
be  detected  or  not  detected,  the  incidence  of  undetected  faults  and  BIT  diagnostic 
errors  would  be  equal  to  F^s  x  (1-Q).  On  the  other  hand,  false  alarms  (FA) 
present  a  more  complex  issue  for  the  BIT  designer.  He  cannot  control  the  inci¬ 
dence  of  "intermittents ,"  nor  can  he  control  the  frequency  with  which  organiza¬ 
tional  or  intermediate  level  AGE  will  detect  and  verify  the  faults  detected  by 
PM /BIT.  We  suggest  that  many  apparent  false  alarms  result  from  detection  of 
real  faults  that  arc  not  corroborated  by  other  means,  and  that  often  cannot  be 
reproduced  at  the  time  of  the  maintenance  actions  which  result.  These  causes 
of  false  alarms  are  beyond  the  scope  of  PM /BIT  design.  For  the  above  reasons, 
the  optimization  equations  make  use  of  an  estimated  FA  rate  as  specified  in  the 
system  design  specification. 

When  undetected  faults  occur,  experience  shows  that  users  will  judge  the 
subsystem  to  be  defective  even  though  PM /BIT  provides  no  such  indication. 

When  a  fault  is  observed,  but  its  location  is  unknown,  any  LRU  in  the  related 
functional  path  could  be  defective.  LRUs  of  that  functional  path  tend  to  be  se¬ 
quentially  replaced,  one-by-one ,  until  the  symptom  is  no  longer  apparent.  In 
the  mean,  this  would  lead  to  the  replacement  of  slightly  more  than  half  the  LRUs 
in  the  path.  By  this  logic  the  rate  of  invalid  maintenance  actions  would  be 
F  x  (1-Q)  x  0.5  (N+l) ,  where  N  is  the  average  number  of  LRUs  in  the  function¬ 
al  paths  of  the  subsystem.  Using  averages  for  Q  and  N,  a  preliminary  estimate 
of  effectiveness  (ET)  can  be  made  as  follows: 
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(Eq.  34) 


Et  — _ ^rs  _ 

F  +  F  x  (i-Q)  x  O.5  (N  +  1.)  1  +  (1-Q)  x  0.5  (N  +  1) 

rb  rs 

In  other  words ,  since  all  the  signals  of  the  design  have  initially  been  des¬ 
ignated  for  measurement,  PM/BIT  effectiveness  is  determined  by  the  quality 
of  measurement  and  the  LRUs-per-path  variability  of  the  subsystem.  Later, 
when  measurements  of  least  worth  are  eliminated  by  cost  effectiveness  trade¬ 
offs,  additional  maintenance  actions  will  arise  from  the  undetected  faults  and/or 
ambiguous  fault  isolation  which  thereby  results.  A  more  detailed  calculation 
of  effectiveness  will  be  made  at  that  time.  The  above  approximation  of  E,^  is 
sufficient  for  initial  calculation  of  the  maximum  likely  effectiveness  for  the  se¬ 
lected  subsystem  and  PM/BIT  concepts.  It  does  not,  however,  include  the  false 
alarm  factor  and  is  therefore  somewhat  optimistic. 

Consider  the  relationship  between  ET ,  Q ,  and  N ,  depicted  graphically  in 
Fig.  4-8.  From  the  relationship  expressed  by  this  plot,  it  follows  that  high  de¬ 
grees  of  PM/BIT  effectiveness  mandate  that  the  quality  of  sensors  and  threshold¬ 
ing  functions  be  extremely  high.  Reconsider  the  initial  values  of  Q  in  the  signal 
matrices ,  and  define  them  such  that  they  are  in  a  region  consistent  with  the 
number  of  LRUs  per  path,  and  high  enough  to  produce  the  specified  effective¬ 
ness.  It  must  be  remembered  that  this  must  be  a  design  goal  for  the  circuit /LRU 
designers,  and  that  the  value  of  Q  must  allow  for  the  possibility  that  measure¬ 
ment  of  some  signals  may  have  to  be  deleted  for  reasons  of  cost  effectiveness, 
and  also,  that  the  calculations  of  Q.are  at  best  inexact. 

4.4.6  Initial  Estimate  of  Mean  Test  Time  (Step  3E) 

Mean  Test  Time  (Mtt)  from  the  subsystem  design  control  specification  is  the 
time  for  PM/BIT,  in  the  mean,  to  detect  and  isolate  faults.  Maintenance  techni¬ 
cian  activities,  administrative  processes,  and  their  related  times  are  excluded, 
so  that  Mtt  is  a  measure  of  how  fast  PM/BIT  operates,  from  the  time  when  a 
primary  output  signal  fails  to  the  time  that  a  fault  isolation  conclusion  is  displayed 
to  the  maintenance  technician.  This  is  determined  by  the  time  factor,  sample 
rate,  and  failure  rate  data  in  the  primary  and  secondary  output  signal  matrices: 

•  the  sample  rate  entry  represents  the  designer's  estimate  of  how  often 
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Q  -  0.99 


Q  -  0.95 


AVERAGE  SENSOR  QUALITY.  Q 


Fig.  4-8  Effactivarwsi  as  a  Function  of  Measurement  Quality  and  LRUs  per  Path 


BIT  checks  each  signal,  and  may  vary  from  continuous  to  some  rather 
accurately  defined  iteration  period  (interval) 

•  the  time  factor  is  the  designer's  estimate  of  how  long  it  will  require  for 
a  detected  primary  or  secondary  signal  failure  to  be  processed  to  a  con 
elusion  (i.e. ,  to  be  evaluated  and  the  results  displayed) 

•  the  failure  rates  of  each  signal  path  determine  the  relative  contribution 
of  each  path  to  the  overall  figure.  That  is,  the  times  associated 
with  the  highest  failure  rate  path  contribute  more  weight  to  the  Mtt 
figure  than  those  of  the  most  reliable  paths. 
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In  many  cases,  it  will  be  obvious  by  inspection  that  a  given  PM/BIT  design 
concept  will  be  capable  of  operating  fast  enough  to  satisfy  the  corresponding  M^ 
requirement.  In  the  event  that  the  PM  /BIT  design  does  not  obviously  meet  this 
requirement ,  then  a  more  detailed  initial  estimate  of  M^  may  be  made  and  com¬ 
pared  with  the  specified  requirement. 

If  a  more  detailed  estimate  of  M^  is  desired ,  this  may  be  computed  from  the 
time  factors,  sample  rates,  and  failure  rates  in  the  signal  matrices: 

•  take  the  sum  of  the  reciprocals  of  all  the  sample  rates  for  the  sensors 
of  each  signal  path;  this  provides  the  "worst  case"  time  to  acquire 
fault  detection  /isolation  data  for  each  of  the  paths.  In  the  case  of  off¬ 
line  BIT,  the  definitions  of  sample  rates  account  for  the  time  necessary 
to  use  the  BIT  capability,  as  well  as  its  inherent  iteration  rate 

•  multiply  each  of  the  above  path  times  by  the  path  failure  rate;  this  pro¬ 
vides  the  weighted  contribution  of  each  path  to  the  overall  average 
acquisition  time 

•  take  the  sum  of  the  above  weighted  path  times,  and  divide 

it  by  the  overall  subsystem  failure  rate;  this  gives  the  estimated 
overall  subsystem  data  acquisition  time 

•  add  the  above  acquisition  time  to  the  estimated  processing  time 
required  by  the  evaluation  function,  and  the  estimated  average 
time  to  display  the  results;  this  will  provide  a  conservative 
estimate  of  for  the  design. 

4.4.7  PM /BIT  Cost  Estimates  (Step  3F) 

The  PM /BIT  design  concept  is  still  too  preliminary  to  provide  a  definition  of 
the  data  necessary  for  life  cycle  cost  estimating.  For  this  reason,  the  signal 
matrices  have  been  developed  using  LRU  production  costs. 

The  DoD  standard  definition  of  production  costs  includes  the  cost  of  de¬ 
sign,  production,  material,  and  test.  Wherever  PM /BIT  uses  portions  of  the 
subsystem  which  would  be  present  even  if  there  were  no  BIT  requirement  im¬ 
posed,  the  costs  chargeable  to  PM/BIT  are  zero.  Likewise,  if  it  is  required  that 


these  items  have  expanded  capacity  to  meet  PM /BIT  requirements,  then  pro-rated 
costs  should  be  employed. 

After  reviewing  the  costs  in  the  signal  matrices,  the  designer  should  now 
take  their  sum,  and  add  this  to  the  costs  of  evaluation  and  display.  This  pro¬ 
duces  a  PM /BIT  initial  cost  estimate  which  may  be  compared  with  the  specified 
subsystem  design  cost  envelope. 

4.4.8  Adjustment  of  PM/BIT  Design  Concept  (Step  3G) 

Thus  far,  the  design  concept  is  one  where  a  defined  PM/BIT  architecture 
measures  all  primary  and  secondary  output  signals  and,  therefore,  has  fault 
isolation  capabilities  limited  only  by  the  quality  of  measurement  and  evaluation. 
The  concept  is  accompanied  by  initial  estimates  of  effectiveness,  mean  test  time, 
and  BIT  production  costs.  These  estimates  should  now  be  compared  with  the 
like  parameters  of  required  subsystem  performance  and  costs.  If  the  estimated 
parameters  are  found  to  meet  these  requirements ,  no  adjustment  to  the  design 
concept  is  necessary  at  this  time.  If  one  or  more  of  the  estimated  parameters  do 
not  meet  the  requirements  of  the  specification,  the  design  concept  should  be  ad¬ 
justed. 

If  the  costs  of  the  BIT  design  concept  are  in  excess  of  the  specified  cost 
envelope,  then  adjustment  is  possible  by  removing  measurements  of  least  worth, 
to  the  point  where  costs  fall  within  the  limit,  but  effectiveness  and  mean  correc¬ 
tive  maintenance  time  are  still  in  compliance  with  the  specification. 

If  there  is  insufficient  effectiveness,  measuring  or  evaluation  quality,  these 
may  possibly  be  increased  to  the  limit  of  additional  costs  within  the  cost  envelope. 
In  the  (unlikely)  event  that  mean  test  time  is  too  long,  architectural  or  pro¬ 
cessing  changes  to  the  design  concept  will  be  required  to  increase  PM /BIT  speed. 
Again,  such  changes  must,  of  necessity,  be  made  within  the  specified  cost  enve¬ 
lope. 

Recognize  that  effectiveness  and  mean  test  time  requirements  are  to  be 
balanced  against  cost,  and  that  the  goal  of  this  effort  is  to  meet  the  capability 
requirements  within  the  specified  cost  envelope.  If  the  parameters  of  the  sub¬ 
system  design  control  specification  are  realistic  in  this  respect,  it  should  be 
possible  to  derive  a  PM/BIT  design  concept  which  is  in  compliance.  If  none  of 


the  trial  PM /BIT  design  concepts  can  be  adjusted  such  that  their  estimated 
parameters  converge  within  a  reasonable  degree  (approximately  10%)  with  those 
specified,  then  it  will  be  necessary  to  recommend  changes  to  the  specification, 
or  possibly  to  the  overall  subsystem  design  concept,  since  the  latter  may  simply 
be  too  difficult  and  expensive  to  test. 

In  the  great  majority  of  cases,  the  PM /BIT  design  concepts  derived  by  this 
methodology  will  be  expected  to  suffer  from  an  excessive  cost  estimate.  This  is 
to  be  expected  because  our  initial  approach  is  that  all  possible  signals  have  been 
deliberately  designated  for  measurement  and  evaluation.  This  results  in  near¬ 
ideal  fault  detection  and  fault  isolation  capability.  In  this  case,  adjustment  of 
the  design  concept  should  be  carried  out  as  discussed  in  the  following  para¬ 
graphs  . 

4. 4. 8.1-  Eliminate  "Virtual"  Test  Measurement  Hardware  -  Whenever  the  paths 
leading  to  two  or  more  primary  output  signals  intersect,  the  status  of  the  com¬ 
mon  circuitry  may  be  deduced  from  the  status  of  the  associated  primary  outputs 
(e.g. ,  when  both  primary  output  signals  fail  simultaneously,  it  is  deductively 
certain  that  the  only  possible  single-point  failure  must  be  located  at  the  common 
circuitry.  The  PM /BIT  designer  should  evaluate  the  functional  flow  diagrams  to 
identify  these  intersections,  and  the  measurement  hardware  at  each  such  inter¬ 
section  should  be  deleted  from  the  design  concept.  BIT  costs  may  then  be  re¬ 
computed  to  determine  whether  the  savings  are  sufficient  to  bring  the  design 
concept  within  the  specified  cost  envelope.  Effectiveness  and  mean  test  time 
will  not  have  been  affected  significantly,  and  hence  need  not  be  recomputed. 
Figure  4-9  illustrates  the  concept  of  a  virtual  sensor. 

1.4. 8. 2  Delete  the  Least  Cost  Effective  BIT  Capabilities  -  Further  cost  reduc¬ 
tions  require  a  series  of  trade-offs  to  delete  those  capabilities  which  are  least 
cost  effective.  Each  deletion  will  reduce  BIT  effectiveness  by  causing  invalid 
maintenance  actions  because  faults  are  either  not  detected  or  ambiguously  iso¬ 
lated.  When  initially  computing  effectiveness,  these  invalid  ir '’ntenance  actions 
were  approximated  as  Frg  x  (1-Q)  x  0.5  (N  +  1)  for  the  overall  subsystem  with 
all  signals  measured  and  evaluated.  Q,  the  measurement  quality  factor,  will 
obviously  be  zero  if  a  given  signal  is  not  measured  any  longer;  therefore  the 


failure  rate  times  0.5  (N  +  1)  would  he  the  expected  rate  of  invalid  mainte¬ 
nance  actions  for  the  deletion  of  a  particular  measurement. 

Recall  that  the  worth  of  all  primary  output  signal  measurements  has  already 
been  computed  in  terms  of  Frp,  Q^,  and  the  cost  of  measurement.  These  values 
of  worth  (W^)  appear  in  the  signal  matrix.  With  the  additional  consideration  of 
path  ambituity,  a  trade-off  algorithm  to  define  the  relative  loss  of  effectiveness 
due  to  the  deletion  of  a  primary  output  signal  measurement  can  be  defined  as: 

EJ  =  W,  x  0.5  (N  +  1)  (Eq.  35) 

d  d 

For  secondary  output  signals,  the  trade-off  is  very  similar,  except 
that  their  computed  worth  must  be  modified.  Recall  that  W.  of  the  secondary 
outputs  was  computed  as  a  function  of  fault  location  uncertainty  resolved, 
measurement  quality,  and  cost  of  measurement,  with  the  apriori  assumption  that 
such  "faults"  had  been  detected  as  primary  output  failures,  hence  they  in  fact 
existed . 
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Thus,  it  is  necessary  to  modify  the  worth  of  a  fault  isolation  sensor  to 
reflect  the  likelihood  that  a  "fault"  exists,  in  order  to  use  this  term  in  trade¬ 
offs.  In  this  case,  the  trade-off  algorithm  for  secondary  outputs  becomes: 

E.  =  W.  x  F  x  0.5  (N  +  1)  (Eq.  36) 

i  l  rp 

which  weights  the  secondary  output  trade-off  in  terms  of  capability. 

Although  the  information  produced  by  measuring  primary  and  secondary 
outputs  is  of  two  distinct  categories  (fault  existence  in  the  one  case,  and  fault 
location  in  the  other) ,  its  quantity  has  been  derived  as  relative  on  a  scale  from 
zero  (no  information)  to  unity  (all  possible  information).  Since  all  the  other 
terms  used  in  computing  worth  and  path  ambiguity  are  directly  interchangeable, 
it  appears  logical  to  compare  values  of  E  directly  for  both  classes  of  signal 
measurements.  The  proposed  trade-off  to  eliminate  the  least  cost  effective 
measurements  is  then  as  follows: 

•  compute  E^  for  all  primary  output  signals 

•  compute  E.,  for  all  secondary  output  signals 

•  order  both  of  the  above  signals  in  terms  of  their  E  values,  from  maxi¬ 
mum  to  minimum 

•  delete  the  signal  measurements  of  minimum  E,  to  the  point  where  enough 
signals  have  been  deleted  to  bring  the  PM /BIT  design  concept  into 
agreement  with  its  cost  envelope. 

4.4.9  Adjustment  of  Design  Concept. Effectiveness  Parameter  (Step  3H) 

Effectiveness  can  now  be  computed  in  a  more  accurate  manner  based  upon 
subsystem  failure  rate,  the  rate  of  valid  maintenance  actions  for  the  subsystem, 
and  the  summation  of  invalid  maintenance  action  rates  for  the  individual  signal 
paths . 

Recall  that  the  subsystem  invalid  maintenance  action  rate  was  Frgx  (1  -  Q) 
x  0.5  (N  +  1).  For  a  given  primary  output  signal,  its  contribution  to  the  rate 
of  invalid  maintenance  actions  as  a  result  of  no  detection,  is  therefore: 

MArid  =  Frp  x  (1_Qd)  x  0.5  (N  +  1) 
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(Eq.  37) 


where  MA  . ,  is  the  rate  of  invalid  maintenance  actions  because  of  no  detect, 
rid 

F  is  the  failure  rate  of  the  signal  path  in  question,  Qd  is  the  quality  factor  of 
the  fault  detection  sensor  (measurement),  and  has  the  value  zero  if  the  signal 
is  not  to  be  measured,  and  N  is  the  number  ox  LRUs  in  the  path  from  input  to 
primary  output. 

We  must  also  consider  the  case  where  faults  are  detected,  but  ambiguously 
isolated  due  to  incorrect  fault  isolation  measurements,  or  because  one  or  more 
secondary  output  signals  are  not  measured.  Consider  a  path  such  as  that 
shown  in  Fig.  4-10  with  a  fault  detected  by  a  sensor  at  point  D,  five  elements 
(LRUs  in  this  case),  and  with  the  LRU  normalized  failure  (F^'s)  indicated.  If 
the  sensor  at  P  reaches  an  incorrect  conclusion,  it  will  point  to  the  group  of 
LRUs  which  do  not  contain  the  fault.  For  the  path  shown  in  the  figure,  the 
fault  isolation  sensor,  when  it  makes  a  "mistake,"  will  point  to  the  "wronff" 
group  of  two  LRUs  60%  of  the  time,  and  the  other  "wrong"  group  of  three  LRUs 
40%  of  the  time.  Thus,  with  a  mistake  rate  of  (1-Q.),  there  will  be  (1-Qj)  x  0.  6 
x  2  LRUs  +  (1-Q.)  x  0.4  x  3  LRUs  (per  unit  of  time)  implicated  as  "bad,"  when 
they  are  really  "good."  Recall  that  these  "mistakes"  can  only  happen  when  a 
primary  output  sensor  indicates  that  a  fault  has  occurred. 


Fig.  4-10  Typical  Signal  Path 


This  also  has  a  significant  impact  on  maintenance.  Every  mistaken  fault 
isolation  measurement  indicates  that  a  group  of  LRUs  contains  a  fault  when  in 
fact  the  fault  is  in  the  other  group  within  its  path.  There  may  be  other  fault 
isolation  sensors  at  other  points  of  the  path,  however: 


•  if  the  other  fault  isolation  sensors  reach  a  correct  conclusion,  the 
outcome  leads  to  confusion  due  to  misleading  and  ambiguous  diagnostics 

•  if  one  or  more  of  the  fault  isolation  sensors  reach  an  incorrect  con¬ 
clusion,  that  is,  the  sensor  at  P  indicates  several  "good"  LRU's  as 
"bad,"  the  other  mistaken  sensor  confirms  the  lie  and  the  actual 
fault  is  in  the  group  of  LRU's  judged  "good" 

•  in  either  of  the  above  cases,  the  preprogrammed  logic  of  a  diagnostic 
program  and/or  the  technical  manual's  trouble  shooting  chart  is  of 
little  use  in  identifying  the  true  malfunctioning  LRU. 

This  resulting  confusion  in  the  minds  of  maintenance  personnel  will  cause 
invalid  maintenance  actions.  These  invalid  maintenance  actions,  contributed  by 
each  fault  isolation  sensor,  can  be  modeled  as: 

MA^  =  (P^  A2)  +  ((1  -  Pf)  x  Al)  x  (1  -  Qa)  x  Frp  x  Qd  (Eq.  38) 

where  MA  ..  is  the  rate  of  invalid  maintenance  actions  due  to  a  given  fault  isola- 
rii 

tion  sensor,  but  is  null  when  the  sensor  is  "virtual,"  P^.  is  the  location  of  the 
sensor  along  the  failure  probability  length  of  the  path ,  where  path  probability 
has  been  normalized  to  unity,  and  is  exactly  the  same  value  of  Pj.  already  deter¬ 
mined  when  fault  isolation  sensor  locations  were  designated,  Al  is  the  number 
of  LRUs  between  the  input  and  the  sensor  at  P^.,  A2  is  the  number  of  LRUs  be¬ 
tween  point  Pj.  and  the  primary  output  signal,  y.  is  tne  quality  factor  of  this 
isolation  sensor,  Qd  is  the  quality  factor  of  the  related  fault  detection  sensor, 
and  Frp  is  the  failure  rate  of  the  signal  path. 

Thus,  for  each  signal  path  in  the  system,  the  rate  of  invalid  maintenance 

actions  is  the  sum  of  MA^d  for  its  primary  output  signal  sensor,  plus  the  values 

of  MA  ..  for  each  of  the  fault  isolation  sensors  along  that  signal  path,  plus  the 
ra 

false  alarms  specified  for  the  subsystem  (FA  x  F  ).  Effectiveness  of  the 
BIT  concept  is  computed  in  this  fashion.  The  overall  invalid  maintenance 
action  rate  for  the  subsystem  is  the  sum  of  the  rates  for  each  signal  path. 

In  turn,  the  effectiveness  of  the  design  concept  can  be  computed  as  the  rate 
of  failure  divided  by  the  rate  of  maintenance  actions,  both  valid  and  invalid. 
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4.4.10  Adjustment  of  Parameter  (Step  31) 


The  initial  estimate  of  M^  must  now  be  modified  to  account  for  the  effect 
of  signals  no  longer  measured.  Obviously,  when  PM/BIT  does  not  measure  a 
primary  output  signal,  fault  detection  and  fault  isolation  must  be  performed 
manually,  and  will  require  more  time  than  if  PM /BIT  were  present. 

The  earlier  e'stimate  of  M^  is  modified  as  follows  to  account  for  the  signals 
no  longer  measured: 

(1)  Recompute  for  those  signals  still  measured  by  PM /BIT,  using  the 
methods  detailed  in  paragraph  4.4.6. 

( 2)  Estimate  the  time  required  to  perform  manual  testing  of  those  signals 
and  paths  no  longer  measured  by  PM/BIT.  For  each  path  which  no 
longer  has  its  primary  output  signal  measured,  assume,  based  on  ex¬ 
perience,  that  manual  fault  detection /isolation  will  require  approxi¬ 
mately  two  hours  depending  on  test  complexity. 

(3)  From  the  signal  matrices,  obtain  the  path  failure  rates  for  those  paths 
which  are  have  PM/BIT,  and  for  those  which  are  tested  manually,  and 
take  the  sum  of  each  of  these  two  categories.  This  will  give  the  over¬ 
all  failure  rate  for  manually  tested  paths. 

(4)  Overall  Mtt  may  now  be  estimated  as  the  weighted  average  of  the  above 
two  values: 


Ubit  X 


manual 


"  manual 


subsystem 


(Eq.  39) 


4.4.11  System  Effectiveness  and  M^t  (Step  3J) 

System  Effectiveness  and  M^  are  not  necessarily  the  same  as  those  derived 
for  the  BIT  design  concept  itself.  Consider  that  any  signal  not  measured  by  BIT 
could  have  been  measured  by  AGE.  Thus,  it  may  be  useful  to  recompute  effec¬ 
tiveness  and  mean  test  times,  with  the  assumption  that  AGE  is  used  to  measure 
all  or  some  of  those  signals  not  measured  by  BIT.  The  estimated  costs  of  such 


AGE  could  also  be  compared  with  those  of  BIT  for  the  same  set  of  signals.  To 
compute  effectiveness  for  a  combination  of  BIT  and  AGE,  do  the  following: 


( 1)  For  every  primary  output  signal  measured  by  AGE ,  compute  the  corres¬ 
ponding  value  of  MA^,  using  the  estimated  quality  of  the  AGE  mea¬ 
surement  as  the  "Q"  value,  and  solving  the  same  expression  used  for 
the  BIT  primary  output  sensors. 

(2)  For  every  secondary  output  signal  measured  by  AGE,  compute  the 
corresponding  values  of  MA^,  using  the  quality  of  the  AGE  measure¬ 
ment  as  "Q,"  but  employing  the  constant  1.2  in  place  of  path  ambiguity 
(i.e.  ,  (P^  x  A2)  +  (1-Pf)  x  Al).  The  1.2  factor  is  based  on  study  data 
and  experience  which  indicates  that  AGE ,  averaged  over  many  recorded 
maintenance  actions,  results  in  about  five  LRU  maintenance  actions  for 
.every  four  faulty  LRUs. 

(3)  Compute  the  overall  value  of  effectiveness  as  discussed  previously,  by 
summing  the  maintenance  action  rates  for  all  paths  in  the  subsystem. 
This  approximates  the  expected  effectiveness  for  any  given  combina¬ 
tion  of  signals  measured  by  BIT,  by  AGE,  or  not  measured  at  all. 

To  determine  the  mean  test  time  for  a  subsystem  using  a  combination  of  BIT 
and  AGE,  additional  factors  must  be  considered.  When  using  AGE,  it  should  be 
possible  to  locate  a  defective  LRU  faster  than  by  the  random  replacement  or 
shotgun  method.  At  the  sane  time,  AGE  introduces  the  additional  time  factors 
for  locating  the  test  equipment,  hooking  it  up,  running  the  test,  disconnecting 
the  test  equipment,  and  returning  it  to  storage. 

For  those  signals  which  are  measured  by  AGE,  the  designer  must  make  a 
reasonable  estimate  of  these  time  factors  and  include  them  as  a  third  term  in 
the  equation  used  for  the  overall  computation  of  The  resulting  solution 

is  the  estimated  subsystem  mean  test  time  for  the  BIT  /AGE  combination. 

In  practice,  the  time  necessary  to  employ  AGE  may  equal  or  exceed  the  time 
required  by  the  shotgun  approach.  Thus,  the  original  estimated  subsystem 
mean  test  time  may  not  change  significantly  when  AGE  is  introduced.  Further, 
it  is  seldom  the  case  that  the  use  of  AGE  will  ever  require  less  than  60  minutes 
per  maintenance  action.  For  this  reason,  as  was  discussed  earlier  in  Section  2 
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of  this  report,  AGE  is  not  recommended  as  a  primary  organizational  level  main- 
tenace  tool  for  avionics. 

4.5  UPDATED  ESTIMATE  OF  FAILURE  RATES  AND  MEASUREMENT  QUALITY 

(STEP  4) 

The  ability  of  a  test  system  to  detect  faults  and  isolate  failures  depends 
upon  the  number  of  measurements  made,  the  quality  of  measurement,  and  the 
failure  rates  md  modes  of  the  subsystem  it  tests.  The  procedures  presented 
thus  far  reflect  these  fundamental  considerations.  Unless  the  failure  rates  and 
measurement  quality  factors  are  known  with  sufficient  accuracy,  the  resulting 
PM /BIT  performance  will  not  agree  with  that  predicted.  Given  the  design  con¬ 
cepts)  just  developed,  and  that  the  mainstream  subsystem  design  has  evolved 
to  a  point  where  failure  modes  and  rates  may  be  more  accurately  defined,  it  is 
then  appropriate  to  update  these  parameters  before  attempting  further  PM /BIT 
optimization. 

4.5.1  Design  Guidelines 

The  quality  of  measurement  factors  for  each  sensor  can  only  be  established  as  target  values, 
l tending  actual  LR  U  and  circuit  design.  The  objective  at  this  point  is  to  establish  target  values  of 
"Q”  for  each  sensor  which  are  consistent  with  the  overall  effectiveness  required  for  the  subsystem. 

Every  circuit  measured  will  have  modes  of  failure  dependent  upon  its  de¬ 
tailed  design  and  components.  "Q^.”  for  a  given  measurement  depends  upon  the 
parametric  failure  symptoms  associated  with  each  mode  of  failure,  upon  the 
failure  frequencies  of  all  the  modes  of  failure,  and  upon  the  ability  of  the  BIT 
sensor /measurement  to  detect  each  of  these  modes.  For  example,  a  given  cir¬ 
cuit  may  fail  with  an  output  which  is  "high,"  "low,"  "missing,"  "distorted," 
"noisy,"  or  parametrically  deficient  in  any  number  of  other  failure  modes  as 
determined  by  the  detailed  circuit  design  and  component  failure  characteristics. 
For  example,  a  measurement  made  on  a  circuit  which  detects  "output  level," 
would  fail  to  detect  many  of  its  other  potential  failure  modes.  A  calculated  esti¬ 
mate  of  the  'Qj.”  parameter  would  require  that  modal  failure  frequencies  be  com¬ 
pared  with  the  modes  detectable  by  the  intended  measurement.  This  would  de¬ 
rive  "Qj."  as  the  quotient  of  overall  failures  likely  to  be  detected  divided  by  total 
failures  likely  to  occur.  This  is  only  possible  for  circuits  that  have  already 
been  designed. 
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The  best  approach  available  to  the  subsystem  designer  at  this  point  is  to 
set  up  measurement  "Q^."  values  which  represent  realistic  estimates  of  what  is 
likely  to  be  achieved  during  the  circuit  design  efforts.  Thus,  the  subsystem 
specification  will  contain  measurement  "Q^."  as  a  requirement  given  to  the  circuit 
designer.  The  values  specified  will  therefore  represent  those  which  must  be 
achieved  to  suppot  the  effectiveness  and  M^  parameters  which  are  also  part  of 
the  subsystem  specification. 

Experience  must  be  conservatively  applied  in  order  to  set  up  realistic  target  values  for  the 
quality  parameter.  A  void  overly  simplistic  or  optimistic  values  for  quality. 

As  a  matter  of  experience,  we  have  found  that  many  BIT  designs  rely  upon 

\ 

simplistic  views  of  the  measurement  process.  More  often  than  not,  it  has  been 
assumed  that  a  measurement  of  signal  nominal  frequency,  voltage,  or  related 
parameters  with  respect  to  "tolerances"  will  detect  all  "out  of  tolerance"  condi¬ 
tions.  This  assumption  is  true  only  in  a  very  limited  sense;  such  measurements 
detect  only  what  they  are  designed  to  detect,  and  therefore  tend  not  to  detect 
unusual  modes  of  failure.  For  example,  a  frequency  measurement  will  not  detect 
jitter,  or  a  rise  time  measurement  on  a  ramp  signal  will  not  detect  nonlinearity, 
or  a  digital  measurement  may  not  detect  so-called  "splinter  pulses."  In  estimat¬ 
ing  the  "Qj."  for  a  given  measurement,  the  system  engineer  must  take  into  account 
such  factors  as  the  above. 

The  uncertainty  with  which  circuit  jauure  rates  may  be  predicted  is  critical  for  PM /BIT  opti¬ 
mization.  but  only  for  those  circuits  that  are  not  measured.  Therefore,  take  particular  care  in 
predicting  unforeseen  reliability  problems  in  circuits  for  which  the  design  roncept  does  not  allocate 
measurement  capability. 

The  design  concept  thus  far  evolved  will  designate  certain  signals  to  be 
measured,  and  may  also  designate  certain  other  signals  as  not  measured.  As 
noted  earlier,  when  a  signal  has  intentionally  not  been  measured,  this  results 
from  a  trade-off  based  on  the  worth  of  that  signal  as  partly  a  function  of  its 
failure  rate.  If  the  actual  rate  of  failure  is  greater  than  the  predicted  rate,  the 
trade-off  is  not  only  invalid,  but  PM /BIT  performance  will  be  less  than  specified. 

For  a  signal  which  is  measured,  an  unexpectedly  high  failure  rate  would 
have  no  adverse  effect  upon  PM /BIT  effectiveness,  and  could  even  lead  to  an  in- 
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crease  in  effectiveness.  This  might  occur  because  the  relative  population  of  de¬ 
tected  failures  would  increase  when  signals  measured  prove  less  reliable  than 
was  expected  during  PM /BIT  optimization. 

4.5.2  Updated  Reliability  Estimates  (Step  4A) 

In  both  the  literature  and  the  experience  of  the  study  staff,  there  have 
been  many  cases  in  which  the  empirical  (actual)  failure  rates  of  a  subsystem  are 
significantly  different  from  rates  predicted  during  the  reliability  analyses  which 
were  part  of  the  design  efforts. 

In  context  with  the  above  fundamental  considerations,  it  is  now  necessary 
to  update  the  signal  failure  rates  in  the  signal  matrices.  It  is  assumed  that  the 
subsystem  design  team  will  have  reliability  engineering  personnel  involved  in  the 
design  process,  and  that  they  will  prepare  a  set  of  estimated  signal  failure  rates 
which  the  PM /BIT  designer  will  use  to  update  his  matrices.  Based  on  this  as¬ 
sumption,  the  process  should  be  conducted  as  follows: 

(1)  Obtain  the  updated  values,  and  enter  them  into  the  matrices. 

(2)  List  the  non-measured  signals,  and  their  updated  failure  rates. 

(3)  Consult  with  the  reliability  engineering  and  circuit  design  personnel 
assigned  to  the  subsystem  development  effort ,  and  review  with  them 
the  estimated  failure  rates  of  the  non-measured  signals.  A  design 
review  meeting  is  recommended  for  this  task,  and  should  consider  the 
possibility  of  critical  circuit  design  errors,  inadvertently  high  com¬ 
ponent  stress  levels,  and  unusually  stringent  circuit  performance  re¬ 
quirements  insofar  as  these  factors  may  lead  to  unforseen  rates  of 
failure . 

(4)  Update  the  failure  rate  data  for  non-measured  signals  to  reflect  the 
results  of  the  above  design  review. 

The  methodology  used  in  the  above  design  review  depends  on  the  nature  of 
the  subsystem  being  designed,  and  the  stage  of  design  reached  at  this  point. 
Methodologies  potentially  applicable,  and  the  circumstances  which  would  suggest 
their  application,  are  summarized  in  the  following  paragraphs,  to  assist  in  the 
selection  of  the  most  practiced  methods  for  the  given  subsystem: 


•  If  any  of  the  circuit  designs  to  be  employed  are  likely  to  be  used  "off- 
the-shelf,"  the  use  of  actual  (empirical)  failure  rates  for  such  modules 
or  circuits  should  be  the  preferred  method.  Data  from  the  AFR  66-1 

or  3M  systems  fall  into  this  category.  However,  in  using  this  data,  dif¬ 
ferences  between  existing  and  projected  applications  should  be  taken  in¬ 
to  account  to  see  if  the  existing  failure  rates  should  be  modified  for  the 
newly  projected  application. 

•  If  there  are  actual  circuit  designs  available,  but  no  empirical  failure 
rates  as  yet,  then  it  is  suggested  that  MIL-HDBK-217  methods  be  used 
to  estimate  signal  failure  rates.  In  using  this  approach,  particular  care 
is  required  in  assessing  the  stress  levels  upon  components,  since  un¬ 
expected  stress  levels  would  lead  to  unrealistically  low  failure  rates. 

•  '  If  the  actual  circuit  designs  are  not  yet  available,  then  consider  using 

the  active  element  count  method.  This  method  is  subject  to  even  greater 
uncertainty  than  the  above  two  alternatives. 

•  If  none  of  the  above  methods  appears  applicable,  consider  the  use  of 
an  extended  regression  analysis  from  previous  designs  of  like  nature. 

A  trend-line  regression  from  several  empirical  values  of  failure  rate  for 
prior  designs  may  yield  a  more  accurate  estimated  failure  rate  than 

the  above  active  element  count  method.  Hence,  in  any  case  where  it  is 
necessary  to  use  the  active  element  count,  consider  the  regression  ap¬ 
proach  also,  and,  if  possible,  do  both.  Select  the  highest  of  the  two 
failure  rates  arrived  at  by  these  two  methods,  and  enter  it  into  the  sig¬ 
nal  matrices  for  use  in  subsequent  optimization,  as  a  conservatism. 

4.5.3  Updated  Measurement  Quality  Estimates  (Step  4B) 

Given  the  final  set  of  updated  failure  rate  data  for  both  primary  and  sec¬ 
ondary  output  signals,  it  will  be  useful  for  the  PM /BIT  designer  to  consider  the 
quality  factors  he  has  associated  with  designated  measurements,  and  update 
these.  Considering  each  measurement  that  has  been  designated,  three  factors 
enter  into  the  choice  of  the  most  "reasonable"  quality  factor  as  the  specified 
goal  for  measurement: 

(1)  Failure  Rate  by  Mode  -  The  more  often  a  signal  fails,  the  more  de- 


sirable  it  is  that  the  associated  sensor  detect  a  high  percentage  of 
failures.  As  noted  earlier,  failures  occur  in  multiple  possible  modes 
for  a  given  signal,  and  these  modes  have  different  sub-rates  of  fail¬ 
ure.  It  is  suggested  that  the  PM /BIT  designer  review  those  signals 
having  failure  rates  in  the  top  10  percentile  of  his  measured  signals, 
and  attempt,  on  the  basis  of  experience,  to  define  the  likely  modes  of 
failure  for  each,  and  their  relative  frequency  of  occurrence. 

(2)  Cost  of  Measurement,  by  Signal  -  Some  generic  circuit  classes  are 
inexpensive  to  measure,  while  others  are  not.  In  circuits  that  yield 
to  inexpensive  sensors ,  it  may  be  relatively  inexpensive  to  obtain 
high  measurement  "Q."  Conversely,  in  circuits  that  require  complex 
and  expensive  sensors,  high  "Q"  may  be  expensive  or  even  impossible 
to  realize. 

(3)  Cost  of  Measurement,  by  Mode  Measured  -  Some  failure  modes  of  a 
given  signal  will  prove  detectable  by  inexpensive  BIT  circuits.  Other 
failure  modes  will  require  relatively  expensive  BIT  implementation. 

For  example,  a  digital  "stuck  at  one"  or  "stuck  at  zero"  measurement 
is  relatively  inexpensive  to  implement  as  BIT,  while  circuitry  to  mea¬ 
sure  other  modes  of  failure  for  the  same  signal  may  lead  to  increased 
costs  out  of  proportion  to  their  frequency  of  occurrence. 

As  a  matter  of  experience,  90%  of  all  subsystem  failures  originate  from  10% 
of  the  circuits  employed  in  their  design.  Hence,  the  quality  factors  given  to  the 
LRU  and  circuit  designers  as  goals  ought  to  be  reviewed  in  detail  with  particular 
emphasis  upon  those  signals  that  are  expected  to  fail  most  often.  It  is  suggested 
that  signals  with  failure  rates  in  the  upper  10  percentile  of  all  signal  rates  be 
individually  evaluated,  as  follows: 

(1)  Identify  the  probable  modes  of  signal  failure,  and  the  relative  fre¬ 
quency  of  each. 

(2)  Estimate,  from  experience,  the  cost  of  BIT  circuits  necessary  to  de¬ 
tect  the  most  prevalent  mode  of  failure,  and  note  the  percentage  of 
failures  thereby  detected. 


(3)  Make  a  similar  estimate  of  modal  detection  cost  for  each  mode,  and  note 
the  related  percentages  of  failures  detected. 

(4)  Set  a  maximum  BIT  cost  for  the  measurement  of  the  signal,  and  select 
the  set  of  BIT  measurement  capabilities  which  "captures"  the  highest 
possible  percentage  of  failures  for  that  signal. 

(5)  Set  the  value  of  as  equal  to  the  failures  detectable,  divided  by  all 
failures  implied  by  the  overall  signal  failure  rate  estimate.  This  will 
be  an  optimistic  value,  as  previously  described. 

(6)  If  the  resulting  Q  is  insufficient  to  meet  the  projected  BIT  effective¬ 
ness  requirement,  consider  using  a  less  expensive  sensor  in  the  mea¬ 
surement  of  the  secondary  output  signal  which  has  the  lowest  failure 
rate  in  the  projected  subsystem ,  and  reassign  its  cost  saving  to  see  if 
the  signal  under  consideration  can  be  measured  with  greater  quality. 

A  uniform  value  of  Q  throughout  the  PM /BIT  configuration  would  net  be 
realistic  for  the  reasons  discussed  above.  The  goal,  in  a  final  update  of  signal 
measurement  Q  values,  is  to  upgrade  measurement  quality  in  high  failure  rate 
signals /modes  by  a  series  of  trade-offs  between  high  and  low  failure  rate  signals 
and  modes.  Reassigning  sensor  capability  in  this  manner  may  result  in  a  higher 
detection  percentage  and  enhanced  effectiveness.  The  final  Q  values  established 
by  that  process  will  be  those  written  into  the  subsystem  specification ,  and  repre¬ 
sent  the  design  goal  for  subsequent  LRU  and  circuit  design. 

4.6  FINAL  CALCULATION  OF  PM/BIT  PERFORMANCE  AND  COST  PARAMETERS 

(STEP  5) 

Effectiveness,  M^,  and  production  cost  may  now  be  calculated  in  their 
final  form ,  for  inclusion  in  the  specification ,  and  to  furnish  a  production  cost 
target.  Actual  calculations  are  simply  a  reiteration  of  the  process  used  to  de¬ 
rive  and  adjust  the  design  concept.  Likewise,  the  updated  data  for  these  cal¬ 
culations  may  be  taken  directly  from  the  signal  matrices. 

Conceivably,  any  of  the  three  required  PM /BIT  parameters  may  or  may  not 
meet  the  parametric  requirements  of  the  system  design  specification.  This  yields 
eight  possible  outcomes ,  when  the  new  calculated  values  are  compared  with  the 
same  values  in  the  design  specification.  Each  of  these  will  be  discussed  in  the 
following  paragraphs. 


•' 


150 


4.6.1  Calculated  Effectiveness,  Mtt,  and  Production  Cost  Meet  the  Requirements 
of  the  Specification  (Step  5A) 

In  the  case  where  all  three  parameters  either  meet  or  exceed  the  original 
values  given  in  the  system  design  specification,  no  further  optimization  is 
recommended.  The  design  concept,  in  its  current  state,  should  be  "written 
into"  the  LRU  design  specifications. 

4.6.2  Calculated  Effectiveness  and  Mtt  Are  Less  Than  Specified,  and  Costs  Aie 
Greater  Than  the  PM/BIT  Production  Cost  Envelope  (Step  5B) 

In  this  case,  the  PM/BIT  design  concept,  and  its  accompanying  subsystem 
design  concept,  are  judged  to  be  not  viable.  If  overriding  system  level  trade¬ 
offs  still  dictate  choice  of  a  subsystem  design  with  such  inherent  PM /BIT  prob¬ 
lems,  then  it  will  be  necessary  to  revise  the  system  level  design  specification  to 
reflect  more  realistic  levels  of  PM /BIT  performance  and  cost. 

4.6.3  Calculated  Effectiveness  and  M^.  Are  not  Acceptable,  while  Costs  Are 
Equal  To  or  Less  Than  the  PM/BIT  Production  Cost  Envelope  (Step  5C) 

In  this  outcome,  further  adjustment  of  the  design  concept  is  necessary.  It 
may  be  possible  to  increase  the  PM /BIT  performance  by  adding  more  measure¬ 
ments  ,  to  the  point  where  projected  production  cost  exactly  meets  the  originally 
specified  cost  envelope.  The  need  to  increase  the  speed  with  which  BIT  oper¬ 
ates,  in  order  to  decrease  the  M^  parameter,  should  be  met  by  one  of  the  follow¬ 
ing  means: 

•  Testing  functions  projected  for  AGE  may  be  reassigned  to  the  PM /BIT 
concept 

•  The  PM /BIT  architecture  may  be  reconsidered 

•  Re-examine  the  PM /BIT  processing  and  display  concepts. 

In  the  above  efforts,  calculations  are  simply  reiterations  of  the  trade-offs 
made  during  formulation  and  adjustment  of  the  design  concept.  The  goal  is  to 
bring  the  PM /BIT  performance  parameters  within  the  originally  specified  values, 
without  increasing  the  cost  envelope  beyond  that  originally  given.  If  this  cannot 
be  done  by  repeated  design  iteration,  then  this  result  becomes  identical  to  that 
discussed  under  Step  5B ,  that  is,  a  non- viable  design  concept. 
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4.6.4  Calculated  Effectiveness  Is  Equal  To  or  Greater  Than  Specified,  but  the 

M  Is  Too  Great,  while  Costs  Are  Equal  To  or  Less  Than  the  Cost  Envelope 
Originally  Specified  (Step  5D) 

Since  is  a  parameter  that  must  be  met  in  order  for  the  overall  system  to 
achieve  its  required  functions  and  availability,  it  will  be  necessary  to  make  the 
design  concept  operate  faster,  while  continuing  to  meet  required  effectiveness, 
and  without  exceeding  the  cost  envelope.  For  this  case,  the  recommended  de¬ 
sign  reiteration  would  be  as  follows: 

•  increase  PM/BIT  operating  speed  by  the  tactics  recommended  in  Step  5C, 
up  to  the  point  where  costs  are  exactly  equal  to  the  cost  envelope 

•  If  the  M^  parameter  is  still  not  met,  then  decrease  the  effectiveness 
parameter  by  removing  the  least  valuable  measurements  in  the  signal 
matrices;  apply  the  cost  reductions  thereby  obtained  to  additional  cap¬ 
abilities  designed  to  increase  the  speed  of  PM /BIT  operation. 

If  the  above  efforts  do  not  produce  agreement  between  effectiveness,  M^ , 
and  costs  calculated  and  those  of  the  design  specification,  then  this  case  also 
reduces  to  a  non-viable  design  concept,  and  the  measures  recommended  in 
Step  5B  must  be  taken.  That  is,  either  the  system  specification  must  be  modi¬ 
fied,  or  an  alternate  design  concept  must  be  selected. 

4.6.5  Calculated  Effectiveness  Is  Equal  To  or  Greater  Than  Specified,  but  Both 
Mtt  and  Cost  Appear  Too  Great  (Step  5E) 

This  case  is  similar  to  the  immediately  preceding  case,  but  more  difficult  to 
resolve,  because  options  for  redesign  are  more  limited.  It  is  recommended  that 
the  design  concept  be  reiterated  as  follows: 

•  remove  measurement  capabilities  by  reiterating  the  trade-offs  made  dur¬ 
ing  adjustment  of  the  design  concept ,  to  the  point  where  the  effective¬ 
ness  parameter  is  exactly  met 

•  apply  the  cost  savings  resultant  from  the  above  step  to  increases  in  the 
speed  of  the  PM /BIT  configuration. 

If  the  newly  calculated  Mtt  is  still  too  great,  then  this  case  also  reduces  to 
a  non-viable  design  concept. 
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4.6.6  Calculated  Effectiveness  Is  Insufficient,  while  and  Cost  Are  Both 
Acceptable  (Step  5F) 

Here,  the  option  is  to  increase  cost  in  favor  of  more  measurement  capability, 
up  to  the  cost  envelope.  If  this  still  does  not  produce  acceptable  effectiveness, 
then  the  designer  must  be  prepared  to  trade  off  PM /BIT  operating  speed  in  favor 
of  still  more  or  better  measurements,  up  to  the  limit.  These  recommended 
trade-offs  are  made  by  reiterating  the  calculations  and  trade-offs  made  durii  g 
formulation  of  the  PM  /BIT  design  concept.  If  no  amount  of  reiteration  results 
in  a  concept  that  jointly  meets  all  three  criteria,  then  either  an  alternate  sub¬ 
system  concept  or  changes  to  the  specified  parameters  will  be  necessary. 

4.6.7  Calculated  Effectiveness  Is  Insufficient,  Mft  Is  Acceptable,  and  Costs  Are 
Too  High  (Step  5G) 

This  outcome  is  similar  to  the  outcome  of  Step  5F,  but  options  for  redesign 
are  much  more  limited.  All  the  designer  can  do  is  trade  off  speed  in  favor  of 
cost  reductions,  and  more  and  better  measurements.  It  is  improbable  that  this 
will  result  in  a  concept  that  meets  all  three  requirements,  and  in  most  cases, 
this  outcome  will  quickly  resolve  to  a  non-viable  solution. 

4.6.8  Calculated  Effectiveness  and  Are  Acceptable,  but  Costs  Are  Too 
Great  (Step  5H) 

In  this  final  case,  it  is  recommended  that  the  BIT  designer  trade  off  system 
speed  against  reduced  costs  first,  then  secondly  trade  off  effectiveness  against 
reduced  costs.  This  order  of  preference  is  judged  best  because  the  uncertainty 
of  predicting  speed  is  less  than  the  uncertainty  inherent  in  predicting  failure 
rates  and  quality  factors  defining  effectiveness. 

4.7  LIFE  CYCLE  COST  TRADEOFF  (STEP  6) 

At  this  point  in  the  methodology,  one  or  more  optimized  PM /BIT  design  con¬ 
cepts  converge  on  a  life  cycle  cost  trade-off  that  will  select  the  most  advanta¬ 
geous  concept  for  implementation.  Since  all  concepts  surviving  Step  5  meet  or 
exceed  the  performance  and  cost  requirements  in  the  subsystem  design  specifi¬ 
cation,  least  life  cycle  cost  becomes  the  criterion  of  choice. 

The  trade-off  should  make  use  of  the  life  cycle  costing  equations  and  pro- 


cedure  detailed  in  Appendix  A.  The  data  required  to  perform  the  trade-off, 
while  still  preliminary  in  some  cases,  should  all  be  available  to  the  PM /BIT  de¬ 
signer: 

•  production  cost  is  a  term  in  the  signal  matrices ,  and  should  be  used 
"as-is"  in  the  equations  of  the  trade-off 

•  the  other  data  required  for  the  trade-off  should  be  acquired  as  "best 
estimates"  from  the  developing  program  logistics  and  management 
planning  functions 

•  in  some  instances,  such  as  with  the  costs  of  maintenance  personnel, 
the  data  sources  are  either  given  by,  or  provided  as  part  of,  the  life 
cycle  cost  trade-off  procedure  of  Appendix  A. 

Any  PM /BIT  design  concept  that  shows  a  positive  result  would  be  one 
whose  life  cycle  cost,  with  BIT,  is  greater  than  without  BIT.  All  such  con¬ 
cepts  should  be  rejected.  Of  the  remaining  concepts,  the  one  with  the  greatest 
negative  incremental  life  cycle  cost  should  be  the  preferred  candidate.  How¬ 
ever,  since  the  PM  /BIT  concepts  are  interwoven  with  the  alternative  prime  sub¬ 
system  design  concepts,  any  PM/BIT  configuration  which  meets  the  criteria 
thus  far  developed,  and  which  results  in  a  net  decrease  in  subsystem  life  cycle 
cost,  should  be  acceptable  to  the  BIT  designer .  That  is,  the  choice  from  among 
two  or  more  acceptable  PM /BIT  concepts  involves  an  overall  system  trade-off  be¬ 
yond  the  scope  of  PM /BIT  optimization,  and  the  overall  subsystem  design  which 
results  will  only  employ  BIT  performance  and  cost  as  elements  of  an  overall 
trade-off. 

4.8  SPECIFYING  LRU  REQUIREMENTS 

For  the  chosen  PM/BIT  design  concept,  the  final  task  of  subsystem  design 
is  to  specify  the  requirements  to  be  imposed  upon  each  LRU  of  the  subsystem. 
The  methodology  we  have  presented  is  designed  to  facilitate  that  effort.  The  in¬ 
formation  required  to  specify  effectiveness ,  Mtt ,  and  cost  envelope  is  present  in 
the  signal  matrices ,  and  the  designer  need  only  calculate  those  values  pertaining 
to  each  LRU  in  order  to  provide  the  required  information. 

In  addition  to  the  overall  performance  and  cost  parameters  of  each  LRU,  it 
is  recommended  that  the  signal  matrices  be  broken  down  by  LRU ,  and  made  part 
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of  the  LRU  specification.  This  information  will  thereby  provide  the  details  of 
which  signals  are  to  be  measured,  the  quality  factor  for  each  measurement,  and 
the  signal  characteristics  that  were  the  basis  for  their  derivation.  In  effect, 
this  provides  the  LRU /circuit  designer  with  a  configuration  which,  if  imple¬ 
mented,  will  meet  his  required  performance  and  cost  targets.  It  also  provides 
him  with  an  engineering  tool  which  may  be  used  to  monitor  his  design  compliance, 
and  make  changes  necessary  to  compensate  for  cases  where  his  design  does  not 
appear  to  meet  these  requirements. 

Similarly,  the  overall  functional  flow  block  diagram  (Level  I),  and  detailed 
functional  path  block  diagrams  (Level  II)  should  be  provided  to  the  LRU /circuit 
designers.  These  serve  the  purpose  of  detailing  the  overall  PM/BIT  concept 
and  its  signal  flow  and  interfaces.  They  are  therefore  a  design  tool  which  as¬ 
sists  in  implementing  the  configuration. 

It  is  envisioned  that  an  end-item  specification  will  be  written  for  each  LRU 
in  the  subsystem,  and  that  it  will  contain  the  following  PM /BIT  parameter  in¬ 
formation  : 

•  LRU  PM /BIT  Effectiveness 

•  Primary  and  Secondary  Output  signals  to  be  measured 

•  Primary  and  Secondary  Stimuli  required  to  support  measurements 

•  the  signal  matrices  defining  the  above  output  signals  and  stimuli 

•  M^t  for  the  LRU ,  in  terms  of  the  time  elements  in  the  matrices 

•  the  LRU  interface  with  the  rest  of  the  subsystem,  in  terms  of  primary 
input  and  output  signals 

•  text  and  narrative  defining  the  architecture  and  functional  requirements 
for  PM /BIT  implementation,  to  clarify  and  explain  the  contents  of  the 
above  information. 

Thus,  the  resulting  end  item  specification  will  define  PM/BIT  in  terms  of 
its  inputs,  outputs,  elements,  interrelationships  between  elements,  and  the  pa¬ 
rameters  by  which  each  element  processes  information.  This  provides  a  com¬ 
plete  technical  description  of  the  design  concept  that  is  to  be  implemented.  It 
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also  provides  detiiiled  technical  information  which  may  be  used  to  monitor  the 
design  implementation,  and  adapt  it  to  the  changing  conditions  and  conclusions 
reached  during  the  detailed  design  process. 


1 5(1 


5.  DESIGN  GUIDELINES  AND  PROCEDURES  -  DETAILED  DESIGN  PHASE 


5.1  BACKGROUND  AND  SUMMARY  OF  METHODOLOGY 


This  section  presents  design  guidelines  and  procedures  for  use  in  LRU 
circuit  design,  prototype  testing,  and  design  acceptance.  These  are  the  final 
stages  of  the  design  process,  during  which  LRU  specifications  are  reduced  to 
actual  hardware  and  software.  For  PM /BIT,  the  designer's  task  is  to  be  certain 
that  this  hardware  and  software  provides  the  effectiveness  and  M^  required  by 
the  LRU  specification,  without  exceeding  either  the  production  cost  envelope  or 
life  cycle  cost  parameters  defined  during  the  system /subsystem  design  process¬ 
es.  The  detailed  PM /BIT  design  effort  resolves  to  a  process  that  monitors  the 
design  for  effectiveness  and  M^,  modifies  it  where  necessary  to  compensate  for 
design  changes,  tests  the  prototype  for  compliance,  and  documents  the  results. 

The  conventional  engineering  methodologies  normal  to  this  phase  of  the  de¬ 
sign  process  are  more  than  adequate  for  the  design  of  PM /BIT  circuits.  The 
need  for  additional  methodology  appears  only  as  a  need  to  relate  detailed  design 
features  to  their  cumulative  effects  upon  overall  performance  of  the  PM /BIT 
function.  Thus,  the  additional  tasks  recommended  in  this  section  are  minimal, 
and  are  to  serve  as  a  means  for  estimating  the  functional  performance  and  ade¬ 
quacy  of  the  detailed  PM /BIT  implementation. 


The  recommended  methodology  consists  of  eight  procedures  superimposed 
on  various  stages  of  the  normal  LRU  circuit  design  process,  as  shown  in  Fig. 

5-1.  During  the  design  of  LRU  circuits,  a  more  detailed  analysis  of  measure¬ 
ment  quality  (Q^.)  is  made,  based  on  the  now-developed  circuits  that  are  to  be 
measured,  and  their  probable  modes  of  failure.  Effectiveness  is  then  recalcu¬ 
lated,  based  on  the  new  values  of  "Q^,".  If  necessary,  trade-offs  are  made  to  add 
more  measurements,  or  increase  the  "Q^."  of  existing  measurements,  within  the 
production  cost  envelope.  While  prototype  hardware  is  being  fabricated,  test 
requirements  are  formulated  to  demonstrate  PM /BIT  performance  during  labora¬ 
tory  testing  of  the  prototype  hardware.  During  the  actual  laboratory  effort, 
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these  tests  determine  specification  compliance,  and  changes  are  made  to  the 
PM /BIT  design  to  remedy  cases  of  non-compliance.  During  the  design  accep¬ 
tance  process,  PM /BIT  performance  factors  are  tested  in  the  same  manner  as 
other  required  performance  parameters. 

Costs  treated  during  this  design  phase  are  both  production  and  life  cycle 
costs.  Production  costs  are  used  as  the  measure  of  the  allowable  cost  of  PM/ 
BIT,  that  is,  as  the  cost  envelope  not  to  be  exceeded  by  the  implemented  de¬ 
sign.  Life  cycle  costs  are  treated  indirectly,  by  accounting  for  those  factors  of 
PM/BIT  design  which  drive  life  cycle  cost:  effectiveness ,  reliability,  and  pro¬ 
duction  cost. 

5.2  CIRCUIT  IMPLEMENTATION  ANALYSIS  (STEP  1) 

As  defined  in  Section  4,  quality  factors  in  the  signal  matrices  are  critical 
design  requirements  that  specify  the  percentage  of  all  possible  signal  failures 
that  must  be  detected  by  each  measurement  sensor.  The  PM /BIT  circuits  must 
be  designed  to  provide  these  "Q  "  values  for  the  LRU  and  its  subsystem  to  meet 
the  required  level  of  effectiveness.  The  first  task  in  LRU  circuit  optimization  is 
to  analyze  the  LRU  and  BL'  circuitry  and  deri/e  estimates  of  measurement  qual¬ 
ity  for  each  primary  and  secondary  output.  Comparison  of  the  required  with  the 
estimated  "Q^"  on  a  circuit-by-circuit  basis,  will  identify  any  cases  where  the 
measurement  quality  specified  cannot  be  met.  This  will  require  trade-offs  to 
either  increase  the  quality  of  measurement,  or  measure  additional  signals.  Fi¬ 
nally,  the  updated  values  of  "Qf"  will  oe  recorded  for  subsequent  recalculation 
of  the  effectiveness  parameter. 

5.2.1  Design  Guidelines 

Do  not  take  a  statistical  approach  to  the  analysis  of  measurement  tolerances. 

In  the  literature  researched  by  this  study,  some  recommend  the  use  of 
statistics  to  set  tolerances  for  BIT  measurements.  Such  methods  rely  upon 
trade-offs  between  buyers'  and  producers'  risks  at  various  standard  deviations 
from  nominal  circuit  parameters.  They  offer  a  convenient  mathematical  proce¬ 
dure  for  determining  how  many  "good"  units  v 111  be  rejected,  or  how  many  "bad" 
units  accepted,  with  a  given  set  of  test  tole’ances.  However,  these  methods 
1  i ve  meaning  only  in  the  context  of  a  single  test  of  each  ruit  in  a  production 
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run.  We  conclude  that  the  statistical  approach  to  setting  tolerances  does  not 
apply  to  tolerances  for  PM /BIT  measurements,  because  a  measurement  that 
passes  once  will  continue  to  pass  unless  there  is  a  physical  change  (e.g. ,  fail¬ 
ure)  in  the  circuit  measured. 

For  purposes  of  evaluating  measurement  quality  make  the  assumption  that  a  sensor  designed 
to  measure /detect  a  given  mode  of  failure  will  do  so  100%  of  the  time. 

Any  signal  will  be  possessed  of  one  or  more  "nominal"  values  of  time,  am¬ 
plitude,  etc.  Absence  of  one  of  the  nominal  values  may  be  defined  as  a  failure, 
and  a  measurement  may  be  devised  to  detect  that  absence.  In  this  abstract 
case,  tolerances  define  how  much  deviation  from  the  nominal  is  regarded  as  a 
"failure."  Either  by  analysis  or  empirically  in  the  laboratory,  a  design  engineer 
can  always  establish  a  measurement  tolerance  which  will,  for  all  practical  pur¬ 
poses,  detect  100%  of  the  failures  he  intends  to  detect. 

As  a  corollary  to  the  above  guideline,  also  make  the  assumption  that  a  sensor  will  not  detect 
any  mode  of  failure  it  was  not  designed  to  detect. 

Absence  of  a  "nominal"  parameter  of  performance  is  not  the  only  condition 
that  may  denote  failure.  Other  conditions  that  may  denote  failure  are  the  pres¬ 
ence  of  a  non-intended  parameter  of  that  signal  (e.g.,  noise,  distortion,  etc.), 
or  the  absence  of  a  non-specified  parameter  of  the  signal,  which  a  BIT  sensor 
will  therefore  not  be  designed  to  detect.  For  example,  consider  the  case  where 
a  signal  has  excessive  "jitter,"  that  is,  lacks  temporal  consistency,  but  no  such 
requirement  was  specified  as  a  required  parameter.  It  is  very  unlikely  that  a 
sensor  would  detect  .such  a  failure,  because  its  design  did  not  anticipate  that 
need . 

5.2.2  Identification  of  Signal  Failure  Modes  (Step  1A) 

The  first  step  in  establishing  the  measurement  quality  factors  is  to  examine 
each  LRU  path  leading  to  both  primary  and  secondary  outpui  signals  and  identify 
the  possible  modes  of  signal  failure.  The  precise  electrical  symptoms  defining 
failure  are  highly  dependent  upon  the  specihe  design  of  the  circuits  which  pro¬ 
duce  the  measured  signals.  However,  recognize  that  there  is  a  potential  for 
mode  ,  of  failure  far  more  numerous  than  generally  anticipated.  As  a  minimum,  it 
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is  recommended  that  the  designer  consider  the  following  modes  of  signal  failure 
for  all  signals  in  his  LRU : 

•  output  gain  low  or  high  •  nonlinearity 

•  shorted  or  open  output  •  wrong  phase  relationship 

•  stuck  at  one/zero  (digital)  •  wrong  timing  relationship 

•  splinter  pulse  (digital)  •  jitter 

•  distortion  •  overshoot /undershoot 

•  wrong  damping  characteristic  •  wrong  rise /fall  times 

•  unspecified  transients  •  excessive  ripple. 

The  intent  of  this  effort  is  to  identify  not  just  the  most  common  signal  fail¬ 
ure  modes,  but  as  many  of  the  uncommon  modes  as  is  possible  to  anticipate.  All 
signals  measured  should  be  tabulated,  along  with  the  signal  failure  modes  iden¬ 
tified  for  each.  The  above  will  provide  a  starting  point  for  subsequent  evalua¬ 
tion  of  the  significance  of  each  mode,  and  the  ability  of  its  assigned  sensor/ 
measurement  to  detect  such  incidence. 

5.2.3  Modal  Failure  Rate  Estimate  (Step  IB) 

The  signal  matrices  carry  a  failure  rate  parameter  for  every  signal  and  its 
related  path.  It  is  recommended  that  the  designer  apportion  this  overall  failure 
rate  term  to  the  identified  failure  modes  of  its  associated  signal.  For  example, 

_  g 

consider  a  signal  with  u  failure  rate  of  200  x  10  /hr,  six  identified  failure 
modes,  and  its  failure  rates  apportioned  as  follows: 


Mode  of  Failure 

F  =  200  X  10  u 
rp 

(1) 

Stuck  at  "One" 

Frl  =  70  X  10-6 

(2) 

Stuck  at  "Zero" 

Fr2  =  70  X  10"6 

(3) 

Marginal  "One"  Level 

Fr3  =  20  X  10”6 

(4) 

Marginal  "Zero"  Level 

Fr4  =  20  X  10~6 

(5) 

"Splinter  Pulse" 

Fr5  =  15  X  10~6 

(6) 

Race  due  to  internal  node 
failure 

Frg  =  5  X  10'6 
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Since  current  reliability  prediction  methods  do  not  'ei  d  themselves  to  such 
an  apportionment,  it  appears  that  the  designer  will  have  to  apportion  largely  on 
the  basis  of  experience  with  circuits  of  similar  design  and  application.  In  some 
cases,  the  MIL-HDBK-217  stress  level  method  may  be  useful  in  predicting  the 
relative  frequency  of  component  failures  associated  with  each  of  the  identified 
failure  modes.  However,  since  the  failure  modes  were  identified  largely  on  the 
basis  of  the  designer's  judgment  as  to  the  causes  of  each  mode,  it  is  not  unrea¬ 
sonable  to  assume  that  he  has  a  grasp  of  the  components  likely  to  be  at  fault, 
and  their  relative  frequencies  of  failure. 

5.2.4  Analysis  of  Failure  Detection,  by  Mode  (Step  1C) 

The  designer  should  now  consider  the  specific  PM /BIT  circuits  and/or  soft¬ 
ware  diagnostics  that  have  been  implemented  for  each  signal  measured  in  the 
LRU ,  and  compare  these  with  the  failure  modes  he  has  identified  for  the  same 
group  of  signals.  The  effort  here  is  to  identify  which  modes  will  and  will  not  be 
detected  by  the  measurement  (sensor,  thresholding  device,  etc.)  that  has  been 
implemented.  Most  experienced  designers  will  have  little  or  no  difficulty  in  mak¬ 
ing  this  judgment,  given  only  the  schematic  and  general  performance  parameters 
of  both  the  circuits  measured  and  the  related  PM /BIT  circuits.  Similarly,  mea¬ 
surements  made  by  software  diagnostics  will  usually  be  easy  to  classify  with  re¬ 
spect  to  their  ability  to  detect  the  given  failure  modes. 

5.2.5  Calculation  of  Signal  Measurement  Quality  (Step  ID) 

Finally,  it  is  necessary  to  calculate  the  estimated  value  for  each  measure¬ 
ment  from  the  data  developed  by  the  above  three  steps  (1A  through  1C).  The 
Qf  value  for  either  a  fault  detection  or  fault  isolation  sensor  is  estimated  as: 

Total  failure  rate  for  modes  detected  by  the  given  sensor 

Q  - - - - ' - — 

f  Total  failure  rate  for  the  signal 

For  example,  with  the  six  failure  modes  identified  for  the  hypothetical  sig¬ 
nal  discussed  in  paragraph  5.2.3,  assume  that  the  sensor  employed  was  judged 
capable  of  detecting  modes  (1)  through  (4),  but  not  modes  (5)  and  (6).  The  Q^. 
for  that  measurement  is: 


The  designer  should  now  calculate  the  Q^.  of  each  implemented  measurement, 
and  enter  these  values  as  updated  "Q^"  factors  in  the  signal  matrices. 

These  resulting  values  of  "Q^"  are  optimistic  because  they  take  only  known 
failure  modes  and  effects  into  account.  The  effects  of  unanticipated  failure 
modes  will,  in  the  deployed  subsystem,  almost  certainly  lead  to  actual  values 
somewhat  lower  than  those  which  now  appear  in  the  matrices. 

5.3  CALCULATION  OF  DESIGN  COMPLIANCE  (STEP  2) 

Given  the  updated  values  of  measurement  quality,  and  an  actual  preliminary 
LRU  circuit  design,  it  is  now  appropriate  to  calculate  the  degree  of  specification 
compliance  inherent  in  the  PM  /BIT  design.  Four  parameters  are  of  interest: 

•  effectiveness 


•  production  cost  of  BIT 

•  life  cycle  cost  of  BiT. 

This  step  provides  a  convenient  way  to  evaluate  each  of  these  four  aspects 
of  the  design ,  and  identify  those  areas  which  require  change  in  order  to  meet 
the  specified  performance  and  cost  targets. 

5.3.1  Calculation  of  Effectiveness  (Step  2A) 


As  noted  earlier  in  this  report,  effectiveness  (ET>  is  the  ratio  of  total  fail- 
ire  rate  (F  )  to  the  maintenance  action  rate  (MAr).'  The  maintenance  action 
rate  has  components  which  are  the  valid  maintenance  action  rate  (the  same  rate 
as  F  ),  and  the  invalid  maintenance  action  rate.  Invalid  maintenance  actions 
result  from  subsystem  failures  not  detected  by  PM/BIT,  and  from  ambiguous 
fault  isolation  of  detected  failures.  For  primary  output  signals,  the  invalid 
maintenance  action  rate  (MA^)  is: 


trid  =  FrPx<1-Qd)x0'5(N  +  1) 


(Eq.  37  of  paragraph  4.4.9) 


where  Frp  is  the  failure  rate  of  the  path,  is  the  quality  factor  associated 
with  its  measurement,  and  N  is  the  number  of  LRUs  in  the  path  from  input  to 
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For  secondary  output  signals,  the  invalid  maintenance  action  rate,  MA^, 


is: 


MA 


-Hi  -  <Pf  *  A2>  +  «‘-V  »  A1>  *  d-Qi)  *  Frp  x  Qd  4.4.„ 

where  P  is  the  location  of  the  secondary  output  sensor  along  the  failure  prob¬ 
ability  length  of  the  path,  where  path  failure  probability  has  been  normalized  to 
unity,  A1  is  the  number  of  LRUs  between  the  input  and  the  sensor  at  P,  A2  is 
the  number  of  LRUs  between  point  P  and  the  primary  output  signal  at  issue,  Q. 
is  the  quality  factor  for  this  fault  isolation  sensor,  is  the  quality  factor  for 
the  related  fault  detection  sensor,  and  F  is  the  failure  rate  of  the  signal  path. 

Now  compute  the  value  of  MAr^  for  each  primary  output  signal,  and  the 
value  of  MA^  for  each  secondary  output  signal  which  is  measured.  (Recall  that 
primary. outputs  which  are  not  measured  have  MA^d  equal  to  Frp  x  0.5(N+1) 
because  in  that  case  Qd  is  null.)  The  summation  of  these  rates  is  the  overall  rate 
of  invalid  maintenance  actions,  MA^,  and  is  used  to  compute  effectiveness,  , 
as:  „ 


rs 


ET  F 


(Eq.  40) 


+  (FA  x  F  )  +  MA  . 
rs  rs'  ri 


where  FA  is  the  specified  maximum  allowable  percentage  of  false  alarms,  and 

MA  .  is  equal  to  MA  .  .  +  MA  ... 
n  nd  ni 

The  computed  value  of  E^,  is  then  compared  with  the  specified  value  to  de¬ 
termine  whether  reiteration  of  the  design  is  necessary  to  bring  the  preliminary 
LRU  design  into  compliance  with  the  specification. 

5.3.2  Calculation  of  Mtt  (Step  2B) 

That  portion  of  M^  within  control  of  the  PM /BIT  designer  is  the  time  ele¬ 
ment  between  occurrence  of  a  failure  and  its  related  fault  isolation.  For  online 
built-in-test,  this  will  usually  be  in  the  order  of  one  second  or  less,  compared  to 
minutes  or  possibly  hours  because  of  various  administrative  delays.  For  off¬ 
line  BIT,  or  for  EIT  configurations  where  there  is  a  fixed  (diagnostic)  time  as¬ 
sociated  with  the  procedural  use  of  the  BIT,  then  a  calculation  of  Mtt  by  the 
method  recommended  in  paragraph  4.4.12  should  be  made,  and  the  result  com¬ 
pared  with  the  requirement  of  the  LRU  specification. 
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5.3.3  Calculation  of  BIT  Production  Cost  (Step  2C) 

Assuming  that  the  production  cost  entry  in  the  signal  matrices  has  been 
kept  up-to-date ,  a  summation  of  these  entries ,  plus  the  centralized  costs  of  the 
evaluation  and  display  elements  can  be  used  to  determine  whether  the  projected 
BIT  production  cost  is  within  the  cost  envelope.  In  the  event  that  PM  and  BIT 
share  evaluation  and  display  functions,  care  should  be  taken  to  pro-rate  costs 
such  that  PM  evaluation  and  display  is  not  charged  to  the  cost  of  BIT . 

5.3.4  Assessment  of  BIT  Life  Cycle  Cost  Factors  (Step  2D) 

No  formal  life  cycle  cost  effort  is  recommended  at  the  level  of  LRU  BIT  de¬ 
sign.  Rather,  the  designer  may  assume  that  the  results  of  life  cycle  cost  anal¬ 
ysis  are  embodied  in  the  parameters  of  the  LRU  design  specification.  Those 
factors  which  determine  LRU  life  cycle  cost  (as  influenced  by  BIT)  should  there¬ 
fore  be  assessed  to  be  certain  they  are  in  agreement  with  the  system  or  subsys¬ 
tem  level  LCC  results. 

Effectiveness,  Mtt,  production  cost,  and  reliability  are  the  LRU  parameters 
which  drive  life  cycle  cost.  The  first  three  have  already  been  addressed  in 
terms  of  whether  or  not  they  comply  with  the  requirements  of  the  LRU  specifica¬ 
tion.  Reliability,  the  remaining  parameter,  may  now  be  considered,  since  actual 
circuit  designs  will  have  made  it  possible  for  reliability  engineering  personnel 
to  calculate  projected  reliability  by  stress  level  analysis.  It  is  recommended  that 
the  projected  failure  rates  in  the  signal  matrices  now  be  updated  with  this  in¬ 
formation.  If  the  newly  calculated  failure  rates  agree  with  the  similar  require¬ 
ments  of  the  LRU  design  specification  then  LRU  life  cycle  cost  will  agree  with 
the  results  of  the  subsystem  life  cycle  cost  analysis. 

5.4  DESIGN  ADJUSTMENT  (STEP  3) 

The  only  trade-off  available  at  this  point  is  between  capability  and  produc¬ 
tion  cost.  If  one  or  more  performance  parameters  do  not  meet  specified  values, 
capability  can  be  increased  up  to  the  limiting  factor  of  production  cost.  Con¬ 
versely  ,  if  calculated  production  cost  is  too  great ,  capability  can  be  traded  off 
in  favor  of  cost  reductions,  to  the  limit  where  effectiveness  and  M^  requirements 
are  barely  met.  Should  such  trade-offs  appear  necessary,  then  the  methods 
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discussed  in  paragraph  4.4.8  should  be  employed  to  determine  additions  or 
deletions  in  terms  of  their  capability  per  unit  of  cost. 

In  the  case  where  calculated  values  of  effectiveness,  and  cost  are  al¬ 
ready  at  or  beyond  the  limits  specified,  then  the  above  trade-offs  cannot  be 
made,  and  it  will  be  necessary  to  obtain  changes  in  the  specification  or  cost 
envelope.  This  action  would  require  life  cycle  cost  analysis  of  the  proposed 
changes,  because  there  is  a  system  level  trade-off  between  increasing  produc¬ 
tion  cost  versus  increasing  life  cycle  cost.  More  BIT  capability  may  tend  to  de¬ 
crease  life  cycle  cost  even  though  production  cost  is  increased.  In  any  event, 
the  necessary  life  cycle  cost  analysis  can  only  be  carried  out  at  the  subsystem 
or  higher  level  of  design. 

5.5  PROTOTYPE  TEST  PLANNING  (STEP  4) 

The  test  of  PM /BIT  capability  should  be  performed  as  an  integral  part  of 
the  laboratory  circuit  design  test  effort.  This  approach  regards  PM /BIT  as 
another  required  LRU  function,  to  be  tested  and  verified  in  tho  same  manner  as 
any  other  specified  function.  The  degree  of  formality,  and  the  format  for  PM/ 
BIT  laboratory  tests  will  be  governed  by  the  specific  resources  and  require¬ 
ments  of  the  mainstream  design  effort.  However,  the  PM /BIT  test  plan  should 
be  sufficiently  thorough,  including  the  following  activities  and  functions  as  a 
minimum : 

•  Tolerance  Verification  -  Tolerances  designed  into  the  prototype  PM  /BIT 
configuration  should  be  verified.  This  activity  should  prove  the  ability 
of  the  chosen  tolerances  to  accept  good  signals,  and  detect  defective 
signals.  Consideration  should  be  given  to  verification  of  tolerances  in 
as  many  modes  of  failure  as  possible  for  each  signal. 

•  Failure  Simulation  -  An  effort  should  be  made  to  simulate  a  failure  of 
every  signal  in  every  mode  of  failure  that  has  been  identified.  With 
relatively  simple  LRUs  this  may  be  possible.  For  very  complex  designs, 
universal  failure  simulation  may  be  too  expensive  or  time  consuming.  As 
a  minimum,  the  PM/BIT  designer  should  prepare  a  list  of  a  statistically 
significant  number  of  randomly  selected  failures  to  be  introduced  into 
the  prototype  hardware. 
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5.6  PROTOTYPE  TESTING  (STEP  5) 


PM /BIT  laboratory  testing  is  superimposed  on  the  normal  prototype  test 
process.  The  key  requirement  is  that  effectiveness  and  M^  values  be  demon¬ 
strated,  just  as  all  the  other  requirements  of  the  LRU  and  its  subsystem  are 
tested.  Generally,  it  will  be  sufficient  for  the  PM /BIT  designer  to  work  as  part 
of  the  laboratory  test  team,  execute  the  PM /BIT  tests,  and  observe  the  other 
tests  in  process  so  that  he  may  note  the  occurrence  of  LRU  design  changes  re¬ 
quiring  compensatory  PM /BIT  redesign. 

5.7  FINAL  DESIGN  ADJUSTMENT  (STEP  6) 

Depending  upon  the  evaluated  results  of  prototype  testing,  there  may  be  a 
requirement  for  changes  to  increase  fault  detection /isolation,  or  for  changes  to 
the  PM /BIT  configuration  in  response  to  changes  in  the  design  of  the  LRU  itself. 
In  either  case,  the  designer  should  retest  to  prove  that  these  changes  had  their 
intended  effects.  The  results  of  this  retest  should  be  documented  along  with 
the  final  results  of  LRU  prototype  testing. 

In  the  event  that  PM /BIT  changes  in  either  or  both  of  the  above  categories 
involve  additional  measurement,  evaluation,  or  display  hardware,  then  the  BIT 
production  costs  should  once  again  be  totalled  to  ensure  that  the  overall  pro¬ 
duction  cost  envelope  is  still  met. 

5.8  QUALIFICATION  AND  ACCEPTANCE  TEST  CONSIDERATIONS  (STEP  7) 

Provision  should  be  made  to  demonstrate  the  functions  of  PM /BIT  fault  de¬ 
tection  and  isolation  during  both  qualification  testing  and  individual  acceptance 
testing  of  the  production  LRUs,  subsystems,  and  systems.  The  degree  and 
formality  of  such  PM /BIT  test  requirements  would  be  of  a  level  consistent  with 
the  overall  LRU  qualification  and  acceptance  testing  efforts.  The  approach  here 
is  simply  that  PM /BIT  fault  detection  and  isolation  results  determine  effective¬ 
ness  and  M  achieved  by  the  systems  and  LRUs  under  test,  and  that  tests  of 
these  functions  receive  the  same  level  of  consideration  as  do  tests  of  all  other 
LRU  functions.  It  is  recommended  that  test  plans  make  use  of  failures  occurring 
naturally  to  the  LRU  while  testing  is  in  progress,  plus  a  significant  number  of 
randomly  chosen  failures  to  produce  a  statistically  significant  measure  of  PM/ 

BIT  performance. 
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5.9  DOCUMENTATION  OF  PM/BIT  DESIGN  AND  PERFORMANCE  (STEP  8) 


At  the  conclusion  of  the  engineering  design  effort,  when  the  LRU  and  its 
host  subsystem  have  been  qualified,  it  is  recommended  that  the  PM /BIT  design 
documentation  originated  by  this  methodology  be  preserved  for  two  potential 
future  uses: 

(1)  The  signal  matrices  and  the  Level  I  and  II  Functional  Block  Diagrams 
contain  a  very  detailed  set  of  information  useful  in  the  preparation  of 
maintenance  technical  orders.  Use  of  this  information  in  that  manner 
is  recommended  to  optimize  the  instructions  to  maintenance  personnel 
so  that  they  are  able  to  make  the  best  possible  use  of  the  PM /BIT 
capability . 

(2)  These  data  should  also  be  retained  for  record  purposes.  Empirical 
measurements  of  PM /BIT  performance  with  deployed  systems  may  be 
made,  and  resolution  of  issues  arising  from  field  experience  would  be 
facilitated  if  the  data  is  available  to  engineering  personnel  on  a  more 
or  less  permanent  basis. 


ABBREVIATIONS  AND  TERMINOLOGY 


ATE  -  Automatic  Test  Equipment. 

BIT  -  Built-In-Test. 

BIT  Performance  Terminology: 

False  Alarms  -  in  which  PIT  falsely  identifies  an  LRU  as  a  malfunctioning 
unit  where,  in  fact,  there  is  no  malfunction. 

BIT  Diagnostic  Errors  -  in  which  BIT  incorrectly  isolates  an  actual  fault 
to  one  or  more  non-malfunctioning  LRU's. 

Undetected  Failures  -  in  which  BIT  fails  to  detect  a  malfunctioning  LRU. 

BIT  Ambiguity  -  in  which  BIT  detects  a  fault  and  correctly  isolates  to  two 
or  more  LRU's. 

Intermittents  -  in  which  an  electrical  malfunction  is  present  only  at  certain 
times,  and  which  at  all  other  times  appears  to  be  a  false  alarm. 

FME A  -  Failure  Mode  and  Effects  Analysis: 

Input /Stimulus  Signal  Matrix  -  a  list  of  all  stimuli  provided  to  the  system 

(in  terms  of  units,  amplitudes,  nominal  values,  and  tolerances)  by  mode 
of  the  subsystem  operation. 

Level  I  Functional  Flow  Block  Diagram  -  an  overall  diagram  of  the  conceptual- 
subsystem  system  architecture,  showing  its  inputs,  outputs,  elements, 
and  interrelationships;  emphasis  is  placed  on  defining  the  functional  path 
associated  with  each  required  subsystem  function. 

Level  II  Functional  Flow  Block  Diagrams  -  define  the  functional  paths  in  the 
same  terms  as  above,  but  in  a  more  granular  manner. 

Output  Signal  Matrix  -  a  list  of  all  signal  outputs,  showing  their  amplitudes, 
tolerance^,  units,  etc.,  by  mode  of  subsystem  operation. 

PM  Performance  Monitor. 

PM  !<!  !  ■  e  ncompassing  both  PM  and  BIT. 

Requirement  Allocation  Sheets. 

1'L AIDS  Universal  Locator  Airborne  Integration  Data  System. 
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PARAMETERS 


A 
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(or  F 


RP 


(or  F 


RS 
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K 

LCC 

A 

MA 
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-  Operational  Availability  (Generic). 

-  Inherent  Availability. 

-  Operational  Availability  as  recorded  in  the  field. 

-  %  no-defect  removals  due  to  BIT  ambiguity. 

-  %  no-defect  removals  due  to  BIT  diagnostic  errors. 

Repair  in  Place.  Quantity  per  operating  hours. 

-  Estimated  cost  of  PM /BIT  capability  to  measure  a  given  signal. 

-  Mission  Effectiveness. 

-  Relative  loss  of  effectiveness  due  to  the  deletion  of  a  primary 
output  sensor. 

-  Relative  loss  of  effectiveness  due  to  the  deletion  of  a  secondary 
output  sensor. 

-  Test  Subsystem  Effectiveness  -  The  total  number  of  malfunction¬ 
ing  LRU’s  divided  by  the  total  number  of  O-level  maintenance 
actions . 

-  Figure  of  merit  for  the  test  subsystem,  equal  to  U^/Rg^. 

-  %  no-defect  removals  due  to  false  alarms. 

-  Failure  rate  of  a  functional  element. 

-  Failure  rate  of  a  given  functional  path  leading  to  a  primary 
output. 

-  Failure  rate  of  the  subsystem. 

-The  ratio  of  as-designed  MTBF  to  operational  MTBFq. 

-  Life  cycl°  cost  of  the  total  system  or  subsystem. 

-  Mission  failure  rate,  or  1/MTBFq. 

-  Estimated  overall  maintenance  action  rate  for  the  subsystem. 
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MA  . 
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-  Sum  of  MA  .  ,  and  MA  ... 

nd  rn 


MA 


rid 


MA  .. 
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MDT 
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Pt 


-  Rate  of  invalid  maintenance  actions  for  a  given  primary  output 
signal. 

-  Rate  of  invalid  maintenance  actions  for  a  given  secondary  output 
signal. 

-  Mean  administrative  delay  time. 

-  Mean  corrective  maintenance  time. 

-  Individual  corrective  maintenance  task  time  -  the  time  required 
to  complete  an  individual  maintenance  task  or  action. 

-  A.verage  corrective  maintenance  time  required  to  complete  the 
ith  individual  maintenance  task  or  the  ith  individual  mainte¬ 
nance  action,  averaged  over  several  (e.g.,  N)  observations  for 
the  same  (ith)  task  or  action. 

-  Operational  mean  downtime,  including  active  repair  time,  ad¬ 
ministrative  time,  and  logistic  delay  time.  This  includes 
scheduled  and  unscheduled  maintenance  time  (NORM),  logistic 
down  time  (NORS),  awaiting  maintenance  time  (AWM)  ,  and  other 
administrative  or  handling  delay  time. 

-  Mean  preventive  (scheduled)  maintenance  time  plus  technical 
modification  time. 


MTBF  -  Calculated  mean  time  between  failure. 

MTBF^  Operational  mean  time  between  failure.  The  achieved  apparent 

failure  rate  as  reflected  in  AFR-66- 1/65- 11 0  data,  expressed  as 

the  sum  of  all  operating  hours  for  all  systems  divided  by  the 

sum  of  all  maintenance  actions  due  to  an  indicated  malfunction, 

where  the  number  of  maintenance  actions  includes  R  , ,  C,  and 

n  d 

R  . 
r 

-  The  mean  time  in  which  faults  must  be  detected,  isolated,  and 
displayed.  This  parameter  includes  all  diagnostic,  trouble¬ 
shooting  and  maintenance  technician  participation  time. 
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The  average  number  of  LRU's  in  the  functional  paths  of  a  sub¬ 
system,  or  the  number  of  LRU's  of  a  single  functional  path. 

Performance. 

The  probability  that  the  fault  lies  between  input  and  sensor. 

Quality  Factor  -  A  generic  term  referring  to  the  measurement 
or  test  subsystem's  measurement  validity.  The  designer's 
estimate  of  the  percentage  of  measurements  that  correctly  pass 
and/or  fail  a  signal  for  purposes  of  fault  detection /isolation. 

Quality  factor  for  a  fault  detection  measurement. 

Quality  factor  for  a  specific  fault  detection  or  isolation 
measurement . 

Quality  factor  for  a  fault  isolation  measurement. 

Mission  Reliability. 

Figure  of  merit  used  to  express  the  change  in  failure  rate  due 
to  BIT .  The  failure  rate  of  the  system ,  divided  by  the  sum  of 
failure  rate  of  the  system  plus  the  failure  rate  of  BIT . 

No-Defect  removals.  Quantity  per  operating  hour(s). 

Percentage  that  no-defect  removals  are  of  the  total  maintenance 
actions  due  to  a  true  malfunction. 

Remove  and  Replace.  Quantity  per  operating  hour(s). 

Mission  Survivability. 

Mission  time. 

%  no-defect  removals  due  to  undetected  faults. 

The  amount  of  uncertainty  resolved  by  a  given  measurement. 

Test  subsystem  uncertainty  -  The  total  number  of  O-level 
maintenance  actions  divided  by  the  total  number  of  malfunction¬ 
ing  LRU's. 


Worth  of  a  fault  detection  signal  measurement. 
Worth  of  a  fault  isolation  measurement. 
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APPENDIX  A 


BIT  LIFE  CYCLE  COST  TRADE-OFF  MODEL 
1.  INTRODUCTION 

The  BIT  Life  Cycle  Cost  (LCC)  Trade-off  Model  was  developed  to  assist 
system  designers  in  the  selection  of  alternate  BIT  concepts  and  design  features 
through  LCC  trade-offs.  This  model  consists  of  five  mathematical  equations. 

Each  equation  describes  a  simplified  method  of  computing  an  element  of  LCC 
which  is  sensitive  to  the  BIT  features.  On  the  other  hand,  life  cycle  cost  ele¬ 
ments  which  are  insensitive  to  the  BIT  design  have  been  purposely  omitted.  The 
equations  of  the  model  have  been  simplified  to  minimize  the  requirement  for  the 
extensive  input  data  which  usually  characterizes  LCC  models.  As  such,  the  costs 
calculated  by  the  model  should  not  be  viewed  as  the  total  (real  world)  cost  of  an 
LCC  element,  but  rather  as  a  relevant  cost  element  that  is  useful  in  analyzing  the 
cost  impact  of  alternate  designs,  concepts,  and  test  subsystem  features.  As  such, 
the  model  is  configured  to  use  LRU  level  performance  and  design  parameters . 

The  LCC  impact  (delta)  of  the  subsystems  constituent  LRUs  is  summed  by  the 
model  to  provide  the  total  subsystem  incremental  cost  benefit  or  penalty. 

2.  BIT  LCC  TRADE-OFF  MODEL  EQUATIONS 

Implementation  of  a  given  BIT  feature  or  features  will  affect  the  classic 
RDT&E,  Acquisition,  and  Operational  and  Support  Costs  of  the  host  avionic  or 
ground  electronics  system.  Thus,  the  incremental  change  in  life  cycle  cost  is 
the  sum  of  incremental  changes  in  these  three  cost  categories  plus  the  incre¬ 
mental  Availability  and  Flight  Penalty  Cost.  In  the  equations  that  follow, the 
terms  are  defined  as  elements  of  incremental  change  in  these  categories.  The 
decision  for  each  trade-off  takes  the  form  of  a  question:  "Does  the  Life  Cycle 
Cost  of  the  system  increase  or  decrease  if  this  feature(s)  is  incorporated?"  If 
there  is  a  decrease,  then  the  feature  is  accepted.  Conversely,  if  there  is  a 
null  result  or  an  increase,  the  feature  is  rejected.  All  individual  terms  are  of 
negative  sign  for  a  cost  decrease,  or  positive  for  a  cost  increase.  Total  life 
cycle  cost  incremental  change  is  defined  by  the  equations: 


A  LCC  =  A  RDT&E  Cost  +  A  Acquisition  Cost 
+  A  Operation  and  Support  Cost 


* 

+  A  Availability  Cost  +  A  Flight  Penalty  Costs  (Eq.  A-l) 

2.1  INCREMENTAL  RDT&E  COSTS  (Cr). 

Cr  is  the  RDT&E  cost  as  defined  by  DoD  of  a  given  BIT  feature.  In  most 
cases,  this  term  will  be  null.  However,  in  certain  cases  where  the  implementa¬ 
tion  of  a  potential  BIT  feature  requires  unique  research  and  development  or  re¬ 
lated  activity,  this  term  will  be  the  estimated  cost  of  these  efforts.  For  example, 
there  could  well  be  cases  where  a  specific  BIT  feature  might  require  the  develop¬ 
ment  of  a  new  type  of  sensor  to  implement  a  test  point,  or  the  development  of  a 
new  family  of  logic  circuits  with  BIT  provisions.  In  such  cases  the  Cf  term  will 
be  the  estimated  cost  of  these  RDT&E  efforts. 


2.2  INCREMENTAL  ACQUISITION  COSTS  (C  ) 

acq 

The  incremental  Acquisition  Costs  are  the  sum  of  the  Production  Costs  (C^) 
plus  the  Initial  Support  Cost  (C.g) : 


C  =  C  +  C. 
acq  p  is 

2.2.1  Incremental  Production  Costs  (Cp) 


(Eq.  A-2) 


The  incremental  production  costs  are  the  sum  of  the  design  costs  (C^)  and 
the  manufacturing  cost  (Cm) .  The  terms  include  the  impact  of  BIT  features  on 
both  recurring  and  non-recurring  production  costs: 


C  =  C^  +  C  (Eq.  A-3) 

p  d  m 

The  C^  term  includes  such  cost  elements  as  design  engineering,  drafting, 
prototype  work,  etc.  Note  that  the  design  cost  of  a  postulated  BIT  feature  is 
therefore  an  increment  of  cost  added  to  the  fundamental  cost  of  the  LRU  because 
of  the  implementation  of  the  BIT  feature. 


The  Cm  term  is  the  production  cost  of  a  projected  BIT  feature,  and  there¬ 
fore  this  cost  estimate  becomes  an  increment  of  cost  to  the  system  as  the  result 
of  such  BIT  implementation.  For  purposes  of  this  trade-off  algorithm,  the  value 
of  Cm  is  computed  as: 


(Eq.  A- 4) 


C  =  N  (P  +  L)  (1.0  +  A) 
m  p 

where  P  is  the  purchase  cost  of  parts  and  material  for  the  BIT  feature  in  a 
single  production  unit,  L  is  the  labor  cost  necessary  to  fabricate  the  BIT  feature 
into  the  single  production  unit,  A  is  the  administrative  cost  of  adding  that  BIT 
feature  to  the  production  process ,  and  includes  such  factors  as  burden ,  profit , 
etc.,  expressed  as  a  fraction  of  production  costs,  and  is  the  number  of  pro¬ 
duction  LRUs  expected  to  incorporate  the  BIT  feature  in  question,  i.e.,  N^ 

=  number  of  .systems  produced,  times  the  number  of  LRUs  per  system. 

2.2.2  Incremental  Initial  Support  Costs  (C.  ) 

IS 

The  incremental  Initial  Support  Costs  are  the  sum  of  the  test  equipment  and 

test  software  costs  (C. )  plus  the  cost  of  the  initial  spares  (C  ) : 

t  s 

cis  =  Ct  +  cs  (Eq.  A -5) 

A  given  BIT  implementation  may  influence  the  cost  of  test  equipment  and 
software  required  to  support  the  resulting  system.  For  this  reason,  the  trade¬ 
off  model  provides  the  Ct  term  to  account  for  these  factors.  Ct  is  competed 
based  on  the  designer's  estimate  of  the  impact  (if  any)  that  his  postulated  BIT 
feature(s)  may  have  on  the  cost  of  a  set  of  test  equipment  and  test  software, 
should  that  BIT  be  incorporated-. 

Ct  =  SO  +  NQ  (TOw  -  TOwq)  +  SID  +  NID  (TIDw  -  TID^)  (Eq.  A-6) 

where  SO  is  the  estimated  cost  change  in  Organizational  Level  software  design  as 
the  result  of  the  given  BIT  feature(s),  NQ  is  the  number  of  Organizational  Level 
test  equipment  sets  per  site  multiplied  by  the  number  of  sites  to  be  outfitted, 

TO  is  the  estimated  cost  of  a  single  set  of  Organizational  Level  test  equipment 
to  support  the  host  system  with  the  given  BIT  feature(s)  incorporated,  TOwo 
is  the  estimated  cost  of  a  single  set  of  Organizational  Level  test  equipment  to 
support  the  host  system  with  the  given  BIT  feature(s)  not  incorporated,  SID 
is  the  estimated  cost  change  for  Intermediate  and  Depot  Level  software  design 
as  the  result  of  the  given  BIT  feature(s),  NID  is  the  number  of  Intermediate 
and  Depot  Level  test  equipment  sets  per  site  multiplied  by  the  number  of  sites 
to  be  outfitted,  TIDw  is  the  estimated  cost  of  a  single  set  of  Intermediate/ 

Depot  Level  test  equipment  to  support  the  host  system  with  the  given  BIT 
feature(s)  incorporated,  and  TIDwq  is  the  estimated  cost  of  a  single  set  of 


mu 
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Intermediate /Depot  Level  test  equipment  to  support  the  host  system  with  the 
given  BIT  feature(s)  not  incorporated. 

Guidelines  for  the  derivation  and  use  of  the  Ct  term  are: 

One  recognized  description  of  BIT  is  " that  portion  of  the  automatic  test  equipment  which  is 
contained  within  the  system  to  be  tested.  ”  It  follows  that  a  given  BIT  implementation  will  tend  to 
achieve  functions  of  test  systems  within  the  prime  system,  with  consequent  cost  reductions  to  the 
test  equipment.  The  designer  should  consider  this  tendency  in  light  of  the  specifics  of  his  postu¬ 
lated  BIT  feature! s). 

Automatic  test  software,  as  a  very  major  program  cost,  is  driven  significantly  by  the  “ test¬ 
ability "  of  a  given  electronic  design.  BIT  implementation  often  improves  this  “ testability ”  by 
adding  test  points,  control  inputs,  sensors,  signal  conditioning,  or  interface  circuits.  Thus,  it  is  recom¬ 
mended  that  the  designers  of  built-in-test  who  use  this  tradeoff  algorithm  approach  the  estimation  of 
software  cost  change  by  considering  the  effect  the  hardware  implementation  of  BIT  will  have  on  the 
prime  design. 

The  addition  of  BIT  circuitry  requires  a  capability  to  test  that  very  same  circuitry  at  one  or 
more  levels  of  maintenance.  Thus,  in  estimating  the  test  equipment  cost  terms,  the  designer  should 
examine  the  complexity  of  the  BIT  circuits,  and  their  intrinsic  testability,  to  arrive  at  the  impact 
on  the  cost  of  a  set  of  test  equipment. 

In  most  instances  the  effect  of  a  BIT  feature  on  the  quantity  of  ‘‘Test  Equipment  Sets" 
required  for  I  and  D  level  (NID)  will  be  minimal.  Therefore,  this  term  is  a  constant  in  the  equation 
with  or  without  BIT  incorporated. 

The  cost  of  initial  outfitting  spares  (C  )  required  to  support  a  given  num- 

s 

ber  of  systems  at  a  site  may  change  as  a  result  of  a  given  BIT  feature(s).  To 
the  degree  that  the  frequency  of  LRU  removal /replacement  varies  as  a  result  of 
the  BIT  feature(s),  the  number  of  LRU  spares  may  vary.  Thus  the  trade-off 
model  term  Cg  must  account  for  both  the  improved  test  subsystem  effectiveness 
E,p  and  the  change  in  the  LRUs  reliability  (if  any)  due  to  the  postulated  BIT 
feature. 

To  compute  the  incremental  change  in  spares  required  for  a  system  with  a 
given  BIT  feature(s)  incorporated,  it  is  necessary  to  determine  the  required 
number  of  spares  with  and  without  the  feature,  subtract  these  two  values,  and 


assign  a  dollar  value  to  the  change  in  spares  required.  By  this  logic,  C  is 

o 

computed  according  to  the  following  equation : 


cs  =  M  (NWCVNWOCSWO> 


(Eq.  A-7) 


where  M  =  the  number  of  bases,  N  =  the  number  of  spares  per  base  with  the 
postulated  BIT  feature  incorporated,  N  =  The  number  of  spares  per  base 
without  the  postulated  BIT  features  incorporated,  CSw  =  the  cost  of  a  spare 
with  the  postulated  BIT  feature,  and  CSwQ  =  the  cost  of  a  spare  without  the 
postulated  BIT  feature. 

The  number  of  spares  required  (i.e. ,  Nw  or  Nwq)  for  a  given  set  of 
removal  rates  is  an  exponential  function  of  these  rates.  The  change  in  number 
of  spares  required  for  a  given  change  in  removal  rates  is  therefore  nonlinear, 
according  to  the  Poisson  density  function  (constant  Lambda  model)  for  electronic 
failures : 


P(n)  = 


e  At(At)N 


(Eq.  A-8) 


where  P(n)  is  the  probability  of  n  or  more  removals  in  operating  time  t,  with  an 
hourly  removal  rate  A.  Thus,  with  P(n)  as  the  probability  of  N  or  more  re¬ 
movals,  unity  minus  P(n)  is  the  probability  of  not  having  N  or  more  removals, 
and  N-l  spares  will  provide  that  probability  of  no  spares  out -of- stock  condition. 
Operating  time  t  is  the  number  of  operating  hours  per  month  of  the  LRU  under 
consideration  multiplied  by  the  quantity  of  that  LRU  being  supported  at  each 
base,  multiplied  by  the  number  of  months  of  the  provisioning  period  (generally 
one  month  (approx.)  for  Air  Force  avionics  and/or  ground  electronic  systems).  A 

is  the  mean  demand  rate  per  base  as  expressed  by  A  or  A  (where  A  and 

wo  w  wo 

Aw  are  the  mean  demand  without  and  with  the  postulated  BIT  feature) . 

For  existing  equipment: 


(Eq.  A-9) 


MTBF. 


where  MTBF„  is  derived  from  AFR  66-1/65-110  data, 
o 


w 


For  new  designs  or  modified  equipment: 


Ur 


A,,  orX  ~ 
w  wo 


MTBF  (K)  (RB1T) 


(Note  that  this  is  an  approximation, 
since  Uj  is  a  resu.t  of  on -equipment 
plus  remove  and  replace  maintenance*) 

(Eq.  A-10) 


where  UT  =  the  BIT  Uncertainty  as  defined  in  subsection  2.2  of  the  study  report, 
MTBF  is  the  designer's  estimate  of  MTBF  as  derived  from  MIL-HDBK-217,  X  is 
the  ratio  of  the  operational  MTBFQ  to  the  as-designed  MTBF  for  the  particular 
design  defined  in  paragraph  1.6.7  of  the  study  report,  and 


n  _  ALRU 

rbit  - — - 

alru  bit 

(see  subsection  2.3  of  the  study  report). 

The  spares  model  as  defined  above  is  not  only  an  approximation  of  the  initial 
outfitting  spares ,  but  also  omits  consideration  of  such  elements  as  depot  repair 
pipeline  fill,  war  reserves,  safety  stockage  against  random  fluctuations  in  demand, 
etc.  However,  the  model  as  given  will  capture  the  major  cost  of  initial  spares  out¬ 
fitting,  and  is  also  sensitive  to  test  subsystem  design  parameters. 

2.3  INCREMENTAL  OPERATION  AND  SUPPORT  COSTS  (C  ) 

OS 

One  of  the  major  cost  categories  to  be  accounted  for  in  the  trade-off  is  that 
of  operational  and  support  costs.  These  are  all  costs  of  system  ownership  and 
operation,  and  exclude  the  initial  set  of  logistic  resources. 

BIT  is  expected  to  change  the  required  maintenance  effort,  by  affecting  the 
total  number  of  hours  of  maintenance  that  a  system  will  require  during  its  opera¬ 
tional  life.  This  change  in  total  maintenance  hours  is  equated  to  a  change  in 
operational  and  support  costs  by  the  following  computation: 


C  =  (W  + 
os  o 


Wid> 


(Eq.  A-ll) 


where  Wq  is  the  change  in  organizational  level  life  cycle  maintenance  manhours 
due  to  the  BIT  feature! s)  considered  in  the  trade-off,  W.^  is  the  change  in  inter¬ 
mediate  and  depot  level  life  cycle  maintenance  manhours  due  to  the  BIT  feature(s) 
considered  in  the  trade-off,  and  WQ  and  W.^  express  the  expected  change  in  life 
cycle  direct  maintenance  manhours  due  to  the  influence  of  the  BIT  features  under 
consideration.  BIT  will  in  most  cases  increase  the  failure  rate  of  the  system  due 
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to  the  addition  of  BIT  circuits.  At  the  same  time,  the  BIT  capability  will  reduce 
the  amount  of  effort  needed  to  restore  the  system,  by  improving  the  quality  of 
maintenance. 


By  this  logic: 

Wo=To(Xw“ct  >  (Eq.  A-12) 

w  wo 

Wid  •  To  (*w"idw  -  Xwo“ldwo)  A-13> 


where  TQ  is  the  total  life  cycle  operating  hours  of  the  system  (the  product  of  the 

number  of  systems  to  be  built ,  the  number  of  years  of  total  operational  life  of 

these  systems ,  and  the  yearly  operating  hours  of  a  single  such  system) ,  X  and 

w 

Xwq  are  as  defined  in  Eq.  8,  M  .  and  are  the  O-level  mean  corrective 

w  wo 

maintenance  times  for  the  LRU  with  and  without  the  postulated  BIT  feature,  and 
M.d  and  M-d  are  the  I  and  D-level  mean  corrective  maintenance  times'  for  the 


LRU  with  and  without  the  postulated  BIT  features. 


L^  is  the  total  cost  of  a  direct  maintenance  manhour  defined  as: 

lr  =f#=*2»-80 


(Eq.  A- 14) 


where  K1  is  the  annual  direct  cost  of  a  maintenance  technician  (from  AFR  173-10 
this  is  $10,888  for  fiscal  year  1979) ,  K2  is  the  number  of  direct  maintenance 
manhours  produced  by  the  same  technician  in  a  given  month  (from  AFR  173-10 
aircraft  maintenance  and  personnel  data  this  is  56.7  for  fiscal  year  1979),  and  K3 
is  a  factor  of  1.3,  reflecting  the  numbers  of  supporting  personnel  (staff,  base, 
etc.)  required  to  support  a  group  of  maintenance  technicians  (derived  from 
AFR  173-10  FY  1979  data). 

2.4  INCREMENTAL  AVAILABILITY  COSTS  (C  ) 

or 

The  need  to  improve  system  availability  is  one  of  the  major  motivations  for 
using  Built-In-Test .  As  an  axiom ,  military  capability  is  the  product  of  the  num¬ 
ber  of  systems  and  the  availability  of  each: 


By  the  Commutative  Law ,  the  numerical  values  of  N  (the  number  of  sys¬ 
tems)  ,  and  A  (the  availability  parameter) ,  can  be  interchanged  without  effect 
upon  C,  the  capability.  Obviously,  the  cost  of  systems  can  therefore  be  traded 
off  against  the  cost  of  improved  availability.  By  this  logic,  any  improvement  to 
availability  may  be  equated  to  the  cost  of  those  systems  needed  to  produce  the 
same  change  in  capability,  but  without  such  improvement. 

The  BIT  trade-off  model  therefore  includes  a  term  to  express  the  fiscal 
value  of  availability  changes  due  to  the  postulated  BIT  feature(s)  and  is  defined 
as  CQr  which  is  the  worth  of  a  change  in  availability,  where: 


C  =  N  CS  C 
or  p  w  a 


(Eq.  A-16) 


where  Np  is  the  number  of  LRUs  procured,  CSw  is  the  cost  per  LRU  with  the 
BIT  feature,  and  C  is  the  change  in  availability  due  to  the  postulated  BIT 

cl 

feature  and  is  calculated  in  the  model  as: 


C  =  / - ± - •' 

a  ln-W.  * 

V  ctwo  "°/ 


lt¥ct  V 

<  W  ) 


(Eq.  A-17) 


where  the  terms  are  as  previously  defined. 

2.5  INCREMENTAL  FLIGHT  PENALTY  COST  (Cfp) 

When  BIT  hardware  is  added  to  avionics,  it  affects  the  fuel  consumption  and 
performance  of  the  host  aircraft  by  adding  weight.  The  Cfp  term  has  been  pro¬ 
vided  to  account  for  these  effects  in' the  trade-off  model.  In  the  majority  of 
candidate  BIT  implementations  considered,  the  overall  dollar  cost  (C^  )  may  be 
expected  to  be  small,  but  finite.  Essentially  the  term  has  been  included  to 
ensure  that  rare  cases  in  which  the  weight  of  BIT  may  be  unusually  large  are 
penalized  appropriately  in  the  trade-off  process.  Based  on  the  above,  the 

C  -  term : 

fp 

•  Does  not  apply  to  ground  electronic  systems 


Does  not  apply  at  the  detailed  level  of  electronic  or  avionic  design 

Applies  only  to  those  (overall  system  or  subsystem  level)  trade-offs 
where  the  total  weight  of  BIT  hardware  is  greater  than  approximately 
10  pounds. 


1 

! 


The  life  cycle  cost  per  pound  of  added  weight  depends  on  the  class  of 
aircraft ,  the  specific  aircraft  type,  its  payload,  energy  envelope,  or  similar 
measures  of  performance,  and  cannot  be  generalized  from  available  data.  For 
this  reason,  whenever  a  system-level  design  engineer  considers  the  term 
potentially  significant  he  is  advised  to  consult  with  operations  research  and/or 
aerodynamic  engineering  personnel  and  request  the  appropriate  cost  determina¬ 
tion  from  their  sources. 
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APPENDIX  B 


SIMULATION,  AS  APPLIED  TO  THE  OPTIMIZATION  OF  BUILT-IN-TEST 

1.  BACKGROUND 

Since  digital  computers  came  into  general  use  in  the  mid-1950's,  simulation 
of  military  and  economic  systems  has  become  a  commonplace  technique  for  evalu¬ 
ating  system  behavior.  The  simulation  process  is  one  where  a  "model”  is  oper¬ 
ated  to  allow  observation  of  system  functions  over  a  period  of  time. 

Reference  material  for  this  study  indicates  at  least  one  case  where  simula¬ 
tion  was  employed  for  BIT  optimization.  In  the  mid-1960's,  the  Norden  Division 
of  United  Aircraft  employed  a  stochastic  simulation  to  evaluate  the  performance 
of  BIT  in  a  complex  airborne  radar.  This  permitted  improvement  of  system  BIT 
by  a  cut-and-try  method  involving  the  evaluation  of  different  and  progressively 
more  refined  BIT  configurations. 

With  respect  to  this  study ,  the  issue  to  be  resolved  is  whether  or  not  simu¬ 
lation  ,  in  one  form  or  another ,  offers  sufficient  benefits  to  recommend  its  use  in 
general  BIT  optimization.  This  requires  a  consideration  of  the  results  achieved 
vs  the  costs  of  using  simulation.  The  remainder  of  this  Appendix  provides 
further  definition  of  simulation ,  an  evaluation  of  potential  applications ,  and  con¬ 
clusions  as  to  the  cost  vs  benefit  factors  for  each  potential  application. 

2.  DEFINITION  OF  SIMULATION 

Simulation  is  the  process  of  tracing  the  detailed  behavior  of  a  system  model 
through  time ,  to  observe  and  record  performance  data  of  interest .  For  purposes 
of  this  discussion,  the  term  "model"  is  applied  to  the  category  of  mathematical 
or  logical  models  of  systems ,  and  excludes  physical  models  such  as  wind-tunnel 
models,  structural  or  electronic  prototypes,  etc.  Thus,  the  simulation  process 
is  defined  operationally  as  follows: 

•  Identify  the  goals  of  analysis  in  terms  of  the  specific  questions  to  be 
answered,  and  the  significance  of  the  results  obtained,  (e.g. ,  the 
accuracy  and  usefulness  of  each  conclusion) 


•  Identify,  interrelate,  and  describe  the  factors  that  are  to  be  simulated 

•  Prepare  a  (mathematical)  model  that  contains  the  system  description, 
and  prepare  input  data 

•  Code,  debug,  and  process  the  model  to  record  data  descriptive  of 
modeled  system  behavior 

•  Validate  the  model  by  comparison  of  its  performance  with  the  actual 
system ,  using  qualitative  comparisons  and  mathematical  techniques  such 
as  statistical  confidence  testing 

•  Perform  repeated  experimentation,  operating  the  model  with  revised 
system  descriptions,  ranges  of  input  data,  etc. 

Thus,  it  can  be  seen  that  the  usual  simulation  process  involves  scientific 
experimentation  rather  than  the  solution  of  a  set  of  deterministically  exact  equa¬ 
tions.  The  effectiveness  of  a  model  depends  on  the  system  boundaries  chosen, 
the  pertinence  of  its  variables ,  and  the  numerical  values  of  its  parameters ,  in 
that  order.  The  ability  of  a  given  simulation  to  quantitatively  predict  the  future 
state  of  the  actual  system  at  various  times  is  not  regarded  as  a  test  of  its  use¬ 
fulness.  Rather,  the  ability  to  predict  the  relative  changes  in  system  behavior 
resulting  from  simulated  system  changes ,  or  the  ability  to  identify  the  sensitiv¬ 
ity  of  a  system  to  changes  in  input  variables,  are  the  usual  measures  of  useful¬ 
ness. 

3.  BIT  OPTIMIZATION  IN  THE  SIMULATION  CONTEXT 

The  thrust  of  this  study  is  in  the  direction  of  a  design  methodology  useful 
in  configuring  efficient,  optimal  BIT  capability  into  new  electronic  systems.  The 
criteria  of  optimization  are  therefore  function  and  cost.  If  there  were  such 
methodology,  the  present  system  acquisition  process  would  have  to  be  studied 
and  possibly  revised  to  ensure  its  application  at  the  appropriate  stages  of  a  sys¬ 
tem  design.  However  this  study  is  concerned  with  methodology,  and  studies  of 
the  acquisition  process  are  beyc  id  its  scope.  Therefore,  we  are  concerned  with 
the  issue  of  whether  or  not,  and  to  what  degree,  simulation  may  find  usefulness 
as  a  BIT  design  methodology. 


In  considering  the  above ,  there  are  several  axiomatic  characteristics 
of  the  BIT  optimization  process  and/or  the  simulation  technique  to  be  kept  in 
mind: 

•  The  projected  reliability  of  a  system  and  its  elements  is  an  essential 
parameter  for  such  optimization.  This  makes  the  process  stochastic, 
rather  than  deterministically  exact 

•  Historically,  actual  system  and  elemental  reliabilities  are  not  well  cor¬ 
related  with  predicted  values.  Thus,  the  essential  parameter  is  not 
only  stochastic ,  but  often  of  questionable  accuracy  as  well 

•  Almost  all  accepted  electronic  design  methodologies  rely  on  the  solution 
of  exact  systems  of  equations.  There  is  very  little  application  of  the 
experimental  method,  except  as  an  adjunct  to  exact  design  methods 
(e.g. ,  laboratory  debugging  of  circuit  prototypes  is  used  to  confirm 
exact  design  solutions ,  and  to  account  for  the  effect  of  distributed  con¬ 
stants  not  included  in  classic  circuit  equations.  It  is  not  the  primary 
method,  but  only  a  useful  secondary  technique) 

•  The  technical  tasks  necessary  to  perform  simulation  tend  to  be  just  as 
complex  and  lengthy  as  those  involved  in  using  more  exact  methods.  In 
some  cases,  simulation  may  actually  require  relatively  greater  effort. 

The  BIT  Optimization  Study  seeks  a  design  methodology  that  produces  a 
global  optimum ,  or  as  near  perfect  a  local  optimum  as  is  possible  at  the  state-of- 
the-art.  From  this  frame  of  reference: 

•  It  appears  desirable  to  avoid  the  use  of  "cut-and-try"  experimental 
methods  such  as  simulation  wherever  more  exact  methods  are  possible 

•  Simulation  is  rarely  used  by  circuit  designers .  The  ideal  optimization 
technique  would  be  more  in  harmony  with  the  circuit  designer's  normal 
methods ,  to  encourage  ready  acceptance  of  methodology  derived  by  the 
study 

•  The  inherent  uncertainty  in  using  predicted  elemental  reliabilities  as  a 
BIT  optimization  parameter  is  acceptable  because  there  is  no  other 


alternative.  It  would  be  desirable  to  avoid  the  uncertainty  of  simulation 
as  an  absolute  rather  than  relative  predictor  of  system  performance, 
since  this  would  appear  only  to  add  an  unnecessary  element  of  additional 
risk. 

Simulation  is  most  useful  in  solution  of  problems  that  do  not  yield  to  other 
analytical  approaches.  It  is  often  used  to  shed  light  on  the  behavior  of  very 
complex  systems ,  or  to  evaluate  system  behavior  under  limit  parameter  inputs 
not  feasible  with  an  actual  system.  Its  primary  benefit  is  in  these  areas,  and  its 
accuracies  are  relative  to  a  simulation  baseline  rather  than  in  terms  of  absolute 
system  performance  values .  Some  examples  of  such  application  will  be  provided 
to  illustrate  this  point. 

4.  BIT  ALLOCATION  BY  SIMULATION 

As  noted  in  the  introduction  to  this  discussion,  Norden  employed  simula¬ 
tion  to  optimize  the  allocation  of  BIT  to  an  airborne  radar.  Their  procedure 
was  as  follows. 

A  GPSS-language  simulation  of  the  conceptual  radar  was  constructed  to 
describe  the  system  in  terms  of  its  major  assemblies  and  circuit  modules ,  their 
electronic  functions,  and  their  projected  failure  rates.  This  "model"  was  then 
further  amplified  by  including  a  hypothetical  BIT  configuration  in  the  radar 
system . 

The  model  was  then  processed  by  computer.  The  simulation  represented 
a  significant  period  of  simulated  radar  operation,  during  which  time  simulated 
failures  occurred.  The  logic  of  the  model  then  evaluated  the  BIT  configuration 
to  determine  which  of  these  failures  were  detected,  and  which  were  not  detected. 
This  provided  a  measure  of  how  "good"  that  particular  BIT  configuration  was  in 
the  detection  and  isolation  of  system  malfunctions. 

The  system  designer  could  then  modify  the  model  to  improve  the  ability  of 
the  BIT  to  detect  and  isolate  faults.  He  simply  evaluated  the  simulation  data  to 
see  which  system  failures  occurred  often  enough  to  need  BIT,  and  added  this  to 
the  related  system  elements,  while  conversely,  deleting  BIT  functions  where  the 
related  failures  did  not  occur  often  enough  to  warrant  the  cost.  This  process 
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was  aided  by  a  CRT  and  keyboard  that  permitted  interactive  modification  of  the 
model. 

The  process  was  continued  until  the  desired  level  of  BIT  performance  was 
achieved . 

The  above  procedure  resulted  in  a  BIT  configuration  which  was  measurably 
more  effective  as  a  result  of  the  experimental  optimization.  That  is,  it  could  be 
accurately  asserted  that  the  resulting  BIT  configuration  was  quantitatively 
better  at  fault' detection  and  isolation  than  its  original  version,  because  the 
simulation  produced  this  data.  However,  it  must  be  noted  that  the  quantity  of 
improvement  was  relative  to  the  baseline  BIT  originally  simulated,  and  hence 
relative,  rather  than  absolute  as  would  be  the  case  for  a  technique  which  pre¬ 
dicted  actual  system  behavior.  The  absolute  accuracy  of  such  data  would  de¬ 
pend  on  the  validity  of  the  model,  that  is,  upon  its  precise  correspondence  to 
the  actual  system  in  point  of  structure,  gain,  feedback,  etc.  Note  also  that  the 
elemental  failure  rates  employed  as  input  data  were  those  projected  for  the  de¬ 
signs  in  question,  and  were  therefore  subject  to  the  same  errors  found  in  the 
process  of  reliability  prediction. 

It  could  be  concluded  that  the  above  simulation  would  lead  to  more  effective 
BIT  than  the  largely  intuitive  methods  used  prior  to  its  time.  Experience  with 
the  actual  system  (in  the  A-6E  aircraft)  indicates  that  its  BIT  was  in  fact  a  step 
better  than  prior  systems.  However: 

•  There  is  no  way  to  tell  whether  this  configuration  was  either  a  local  or 
global  optimum  with  respect  to  fault  detection  and  fault  isolation 

•  The  model  did  not  tabulate  costs  of  any  kind.  This  was  up  to  the  user 
to  account  for.  He  was  merely  concerned  with  the  improvement  of  func¬ 
tion  by  allocating  BIT  to  points  in  the  system  where  its  need  was  most 
apparent,  and  by  removing  BIT  functions  which  did  not  detect  faults 

of  sufficient  frequency  of  occurrence 

•  The  analysis  did  not  provide  a  known  accuracy  in  predicting  the  actual 
system  BIT  performance,  because  it  could  only  have  been  validated  after 
the  system  was  actually  constructed. 


Such  an  approach  could  be  used  for  BIT  optimization,  but, would  be  ex¬ 
pensive  and  subject  to  the  same  limitations  discussed  above.  It  should  not  be 
completely  ru.  d  out,  but  simpler  and  more  accurate  approaches  would  be 
preferable.  Finally,  it  should  not  be  used  by  personnel  not  specifically  ex¬ 
perienced  in  simulation. 

5.  CIRCUIT  SIMULATION 

Today,  dynamically  exact  circuit  analysis  software  is  available.  If  such 
systems  were  reiteratively  used  to  simulate  failure  of  each  and  every  component 
at  values  between  "shorted"  and  "open,"  this  would  be  considered  a  simulation. 
In  theory,  it  would  provide  a  total  evaluation  of  BIT  capability.  For  example: 

•  Digital  automatic  test  generators  perform  deterministic  simulation  and 
exactly  reproduce  the  "output"  consequences  of  a  digital  gate  failure. 
An  analogous  simulation  system  could  be  developed  to  include  BIT  func¬ 
tional  capability,  thus  permitting  the  fault  detection  and  fault  isolation 
capabilities  of  any  given  BIT  to  be  exactly  predicted 

•  Analog  circuit  design  programs  also  exist ,  and  could  be  adapted  to  the 
same  end,  with  the  same  results. 

Unfortunately,  reiterative  use  of  such  software  would  be  prohibitively  ex¬ 
pensive  in  time  and  computer  costs,  because  it  was  designed  for  such  other 
purposes  as  test  generation  or  circuit  design. 

As  the  state-of-the-art  for  circuit  simulation  improves,  there  may  come  a 
time  when  a  circuit-level  BIT  optimization  software  system  could  be  developed. 
This  would  be  an  expensive  undertaking,  but  would  provide  an  exact  measure 
of  BIT  function.  It  is  suggested  that  the  state-of-the-art  of  test  generation  be 
monitored  to  see  if  such  a  program  would  be  feasible  in  the  future.  Digital 
Automatic  Test  Generators  (ATGs)  are  well  ahead  of  analog  ATGs  and  may 
present  the  first  opportunity  for  such  an  advance.  Analog  ATGs  do  not  yet 
exist,  in  other  than  the  most  elementary  forms. 

With  respect  to  this  potential  future  development ,  two  things  must  be 
emphasized : 
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•  Cost  is  not  a  factor  in  the  processes  inherent  to  these  classes  of  simu¬ 
lators.  Function  could  potentially  be  optimized  by  these  methods,  but 
not  costs  vs  function 

•  Applications  of  such  methods  are  likely  to  be  limited  to  the  circuit- 
module  level  of  complexity  within  the  foreseeable  future.  The  large 
amount  of  computer  time  necessary  to  process  such  algorithms  will 
probably  limit  their  application  to  modules,  rather  than  entire  systems 
or  "black  boxes." 

6.  SENSITIVITY  ANALYSIS 

Simulation  is  often  used  in  cases  where  a  problem  is  insoluble  by  other 
means.  Such  an  application  can  be  suggested  in  the  context  of  BIT  optimiza¬ 
tion: 

•  Assume,  for  purposes  of  discussion,  that  the  current  study  synthesizes 
a  methodology  that  will  produce  an  efficient  BIT  configuration  by  cri¬ 
teria  of  cost  and  function 

•  The  fundamental  uncertainties  of  reliability  prediction  would  still  re¬ 
main,  and  the  optimum  would  be  only  as  good  as  the  failure  rates  used 
as  input  data 

•  It  would  be  desirable  to  know  the  effects  of  such  uncertainty  upon  the 
efficiency  of  a  specific  BIT  configuration  or  configurations. 

A  stochastic  simulation  of  the  kind  discussed  earlier  would  provide  some 
useful  insights  into  the  effects  of  different  elemental  reliabilities  on  the  fault 
detection  and  isolation  capability  of  BIT  configurations: 

•  Construct  a  model  of  the  (B IT-optimized)  system,  and  operate  the  model 
with  the  same  input  data  as  were  used  to  design  that  particular  BIT 
configuration. 

•  Subsequently,  randomly  vary  the  elemental  failure  rates  of  the  system 
components  between  judiciously  selected  limits,  and  observe  the  BIT 
capability  under  those  conditions 


•  This  would  provide  an  insight- into  how  actual  systems  designed  along 
such  lines  would  behave  in  the  field. 

This  analysis  could  be  done  manually  by  simply  repeating  the  optimization 
using  different  element  failure  rates.  However,  this  could  require  literally 
years  of  effort.  Automatic  simulation  would  provide  equivalent  conclusions  in 
only  a  few  weeks  or  months. 

v.  * 

7.  CONCLUSIONS /RECOMMENDATIONS 
v  4 

For  the  immediate  requirement,  simulation  does  not  appear  to  offer  any 

»> 

significant  advantages.  A  more  conventional  method  is  recommended  for  the 
sake  of  accuracy  and  user  acceptability. 

Monitor  the  progress  of  automatic  test  generators  for  the  next  few  years. 
At  some  future  time  these  may  become  adaptable  to  dynamically  exact  simulation 
of  BIT  and  host  circuits,  yielding  exact  measures  of  fault  detection  and  isolation 
that  are  independent  of  reliability  estimates. 

The  impact  of  presently  uncertain  reliability  predictions  on  the  effective¬ 
ness  of  BIT  optimization  could  be  evaluated  by  simulation.  This  could  provide 
useful  insights  that  might  lead  to  improvements  to  future  BIT /Diagnostics 
methodology . 


t 
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SIMULATED  APPLICATION  OF  THE  SUBSYSTEM 
BIT  OPTIMIZATION  METHODOLOGY 

This  appendix  presents  an  example  of  the  BIT  optimization  procedure  of 
Section  4  applied  to  the  E-2C  Advanced  Radar  Processing  System  (ARPS) .  The 
ARPS  was  chosen  because  it  is  a  contemporary  subsystem  incorporating  a  broad 
spectrum  of  technologies,  with  a  requirement  for  high  BIT  effectiveness. 

1.  ARPS  DESCRIPTION 

The  Advanced  Radar  Processing  System  is  a  modification  of  the  AN /APS- 125, 
providing  increased  reliability,  improved  BIT,  increased  detection  range,  and 
automatic  overland  performance  (see  Fig.  C-l).  The  ARPS  is  comprised  of  nine 
LRUs: 

•  Receiver-Converter 

•  Pulse  Generator 

•  Radar  Set  Control 

•  Performance  Indicator 

•  Dual  Pulse  Attenuator-Compressor 

•  Comparator-Filter 

•  Detector  Processor 

•  Digital  Data  Comparator 

•  Digital  Signal  Converter. 

There  are  six  fundamental  input  signals  from  the  aircraft  artennas: 

•  Sum  channel 

•  Difference  channel 

•  Auxiliary  1 

•  Auxiliary  2 
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•  Auxiliary  3 

•  Auxiliary  4 . 

The  sum  and  difference  channel  signals  are  fed  through  the  Receiver-Con¬ 
verter  to  the  Comparator-Filter,  where  unwanted  signals  from  the  antenna  side- 
lobes  are  canceled.  As  shown  in  Fig.  C-l,  AUX  1  and  AUX  2  signals  are  multi¬ 
plexed/demultiplexed  by  LRUs  not  part  of  ARPS.  They  are  then  fed  through 
the  Receiver-Converter  to  the  Comparator-Filter  where  they  are  used  for  side- 
lobe  cancellation.  AUX  3  and  AUX  4  signals  are  direct  inputs  to  the  Receiver- 
Converter  and  are  also  used  for  side-lobe  cancellation. 

The  Dual  Pulse  Attenuator-Compressor  compresses  and  equalizes  the  sum 
and  difference  pulses.  It  sends  clutter  gate  information  to  the  external  inter¬ 
face  (Control  Voltage  Simulator)  and  clutter  envelope  information  to  the  Detec¬ 
tor  Processor  via  the  Digital  Data  Comparator.  The  sum  and  difference  signals 
are  converted  from  analog  to  digital  format  in  the  Digital  Data  Comparator. 

Each  A  to  D  conversion  produces  in-phase  and  quadrature  outputs. 

The  sum  channel  contains  a  digital  delay  canceler  that  supplies  two  eight- 
bit  outputs  in  parallel  to  the  Digital  Signal  Converter.  The  difference  channel 
contains  a  single  delay  canceler  whose  output  is  used  for  real  time  blanking  in 
the  Detector-Processor. 

The  in-phase  and  quadrature  outputs  for  each  moving  target  are  sent  to 
the  Digital  Signal  Converter ,  which  performs  a  fast  Fourier  transform  of  these 
signals.  This  transform  results  in  16  doppler  filter  outputs  to  the  Detector- 
Processor.  Depending  upon  its  radial  velocity,  each  target  return  will  appear 
in  a  particular  filter. 

The  Detector-Processor  determines  a  threshold  level  for  the  output  of  each 
doppler  filter.  If  a  return  exceeds  its  threshold,  it  is  processed  as  a  possible 
target.  Real  time  blanking,  predictive  blanking,  and  noncoherent  integration 
are  performed  on  these  signals.  Resulting  outputs  are  provided  to  the  external 
interface  as  real  time  synthetic  video  and  pseudo-synthetic  video. 
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1.1  PULSE  GENERATOR  FUNCTIONS 

The  Pulse  Generator  provides  the  basic  timing.  A  15  MHz  crystal-con¬ 
trolled  oscillator  is  used  to  generate  the  5,  10,  30,  45,  60,  75,  and  105  MHz 
timing  references  used  throughout  the  system. 

1.2  RECEIVER-CONVERTER  FUNCTIONS 

The  Receiver-Converter  contains  six  similar  channels  for  processing  the 
six  input  signals  (sum,  difference,  and  AUX  1  through  AUX  4).  It  contains  the 
filters,  amplifiers,  and  mixers  necessary  to  produce  a  system  IF  of  30  MHz  for 
each  of  the  six  input  signals. 

1.3  COMPARATOR-FILTER  FUNCTIONS 

There  are  two  main  Comparator-Filter  Functions: 

•  removal  of  wide  band  jamming  from  the  sum  and  difference  channels 

e  removal  of  narrow  band  jamming  from  the  sum  and  difference  channels. 

The  Comparator-Filter  contains  eight  wide  band  correlators  and  two  narrow 
band  correlators  used  to  eliminate  jamming.  For  wide  band  jamming  rejection, 
jamming  signals  are  correlated  against  the  auxiliary  inputs.  For  narrow  band 
jamming  rejection,  autocorrelation  is  required  because  there  are  no  narrow  band 
auxiliary  signals. 

The  Comparator-Filter  also  contains  an  oscillator  amplifier  and  a  power  am¬ 
plifier  which  produces  local  oscillator  inputs  to  the  Receiver-Converter  and 
Multiplexer . 

\ 

1.4  DUAL  PULSE  ATTENUATOR-COMPRESSOR  FUNCTIONS 

The  Dual  Pulse  Attenuator-Compressor  is  a  complex  2.75  MHz  dual  filter 
which  filters,  compresses,  and  equalizes  the  sum  and  difference  channel  signals. 

1.5  DIGITAL  DATA  COMPARATOR  FUNCTIONS 

The  Digital  Data  Comparator  contains  10  SRUs  which  perform  the  following 
seven  functions: 


•  convert  the  incoming  30  MHz  IF  into  in-phase  and  quadrature  video 

•  convert  the  analog  signals  to  a  10-bit  digital  output 


•  cancel  ground  clutter  (Airborne  Moving  Target  Indicator,  AMTI) 

•  generate  automatic  gain  control  for  land  clutter,  jamming  residue,  and 
large  discrete  target  signals 

•  evaluate  doppler  shift  of  the  main  lobe  clutter 

•  detect  large  discrete  targets  in  both  the  main  lobe  and  side  lobes  of 
the  antenna  pattern  and  blank  those  returns  from  the  side  lobes 

•  generate  video. 

1.6  DETECTOR-PROCESSOR  FUNCTIONS 

The  Detector-Processor  detects  and  processes  targets  for  the  tracking 
system.  Among  the  operations  performed  on  the  detected  targets  are  beam¬ 
splitting,  range  rate  calculation,  and  target  report  formatting  into  a  serial  64- 
bit  message.  It  contains  a  computer  which  processes  the  target  data,  computes 
its  characteristics,  formats  reports,  and  controls  outputs  to  the  central  weapon 
system  computer. 

1.7  DIGITAL  SIGNAL  CONVERTER  FUNCTIONS 

The  Digital  Signal  Converter  performs  a  fast  Fourier  transform  on  the  AMTI 
output  of  the  Digital  Data  Converter.  It  uses  the  resulting  frequency  domain  in¬ 
formation  to  determine  the  doppler  shift  of  the  targets. 

1.8  RADAR  SET  CONTROL  FUNCTIONS 
This  unit  is  the  Operator  Control. 

1.9  PERFORMANCE  INDICATOR  FUNCTIONS 

This  unit  has  light  indicators  which  provide  performance  monitoring  and 
fault  isolation  information .  An  arithmetic  logic  unit  counts  the  number  of  con¬ 
secutive  faults  for  each  bit  of  each  fault  data  word  and  recirculates  the  count 
through  a  RAM.  When  15  consecutive  faults  occur,  the  unit  outputs  a  fault  re¬ 
port. 

1.10  IN-FLIGHT  PERFORMANCE  MONITOR  (IFPM) 

The  E-2C  aircraft  In-Flight  Performance  Monitor  integrates  the  performance 
monitoring  and  fault  isolation  functions  (PM/BIT)  of  the  avionics  suite.  ARPS 
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transmits  fault  information  to  the  IFPM  so  that  ARPS  failures  are  flagged  to 
the  operator.  Although  evaluation  is  done  locally  in  the  LRUs,  the  difficulty 
of  personnel  moving  from  LRU  to  LRU  necessitates  a  central  monitoring  point 
such  as  the  IFPM. 

2.  BIT  DESIGN  PROCEDURE 


The  following  steps  describe  application  of  the  subsystem  design  method¬ 
ology  to  the  ARPS.  The  BIT  design  effort  considers  the  technical  guidelines 
described  in  Section  4.  Data  sources  used  in  preparing  the  ARPS  signal  ma¬ 
trices  consisted  of  LRU  and  SRU  logic  diagrams,  schematics,  training,  and 
technical  manuals  supplemented  by  discussions  with  ARPS  engineering  personnel 

SteD  1  Identification  /Analysis  of  Subsystem  Functions 

I 

1  The  initial  step  in  the  BIT  design  methodology  is  to  develop  an  overall 

block  diagram  of  the  conceptual  subsystem  architecture.  Figure  C-l  illustrates 
such  a  diagram.  For  the  purpose  of  illustrating  the  methodology,  input  and 
output  signal  matrices  were  completed  for  two  ARPS  functions  (Range  -  Nor¬ 
mal  Operating  Mode  and  TACCAR  -  Test  Mode).  The  matrices  are  provided 
in  Figs.  C-2  through  C-4.  The  figures  illustrate  preliminary  matrices  that 
have  gone  through  the  initial  steps  of  the  procedure.  The  failure  rates  and 
costs  have  been  extracted  from  the  E-2C  "Maintenance  Engineering  Analysis 
Summary  Sheets." 

Step  2  Functional  Path  Definition 

Next,  functional  path  diagrams  were  drawn  for  the  Range  and  TACCAR 
functions.  These  include  all  subsystem  elements  that  accomplish  these  two 
functions  and  depict  their  relationships.  Figures  C-5  and  C-6  are  the  prelimi¬ 
nary  functional  flow  diagrams .  Input  and  output  signal  numbers  are  noted  on 
the  flow  diagrams  with  the  corresponding  elemental  failure  rates  (Frj). 

For  the  Range  function,  the  functional  flow  is  serial.  The  TACCAR  func¬ 
tion,  however,  typifies  a  functional  flow  with  feedback.  This  is  why  the 
TACCAR  signal  matrix  shows  the  same  failure  rate  (F^)  for  each  output  line. 

Step  ?  Development  of  Bit  Design  Concept 

The  following  tasks,  each  of  which  is  discussed  in  the  designated  subsec¬ 
tions  below,  are  associated  with  developing  a  BIT  design  concept: 
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L 

TBD 

TBD 

SEE  NOTE  ID 

VOLT 

N/A 

M217 

M219 

838 

y 

Y 

Y 

Y 

Y 

85 

1.0 

c 

2.5 

THRESH. 

L 

TBD 

TBD 

SEE  NOTE  ID 

VOLT 

5 

M221 

M223 

665 

y 

Y 

Y 

Y 

Y 

85 

1.0 

300 

2.5 

THRESH. 

L 

TBD 

TBD 

SEE  NOTE  ID 

VOLT 

5 

M221 

M223 

665 

Y 

Y 

Y 

Y 

Y 

85 

1,0 

300 

2.5 

THRESH. 

L 

TBD 

TBD 

SEE  NOTE  ID 

VOLT 

5 

S100 

S110 

185 

Y 

Y 

Y 

Y 

Y 

85 

1.0 

300 

4.26 

THRESH. 

L 

TBD 

TBD 

SEE  NOTE  ID 

VOLT 

5 

S100 

S1 10 

185 

Y 

Y 

Y 

Y 

Y 

85 

1.0 

300 

4.25 

THRESH. 

L 

TBD 

TBD 

SEE  NOTE  ID 

VOLT 

5 

SI2I’ 

227 

Y 

Y 

Y 

Y 

Y 

85 

1.0 

C 

5 

THRESH. 

L 

TBD 

TBD 

SEE  NOTE  (3) 

VOLT 

5 

SI  20 

227 

Y 

Y 

Y 

Y 

Y 

85 

1.0 

C 

5 

THRESH. 

L 

TPD 

TBD 

SEE  NOTE  (3) 

VOLT 

5 

SI  20 

227 

Y 

Y 

Y 

Y 

Y 

85 

1.0 

C 

5 

THRESH. 

L 

TBD 

TBD 

SEE  NOTE  (3) 

!  FRg  =3638  x  10-6  FAILURES/HR  TOTAL  COST  =  $105.5^ 

i  > 

Dn  circuitry,  and  is  the'cumulative  sum  of  the  signal  path  input  to  the  output  of  the 

IBIT.  EXTRINSIC  BIT,  IN  THE  FORM  OF  SENSORS  AND  TEST  TARGETS,  PROVIDE  THE  ADDITIONAL  BIT  REQUIRED 

) 

AIMING  FUNCTIONAL  CLEM£MTS. 


Fig.  C-2  Preliminary  Output  Signal 
Matrix  (Range  Function) 
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SIGNAL 

NO. 

SIGNAL 

NOMEN¬ 

CLATURE 

RELATED 
FUNCTION/ 
NAME  / 
NUMBER 

FUNCT  NO. 

CLASS 

ANALOG 

DIGITAL 

DISCRETE 

RF 

VIDEO 

c 

i 

MODE 

NAME 

enom 

eMAX 

emin 

AMPLITUDE 

1 _ 

UNIT 

TOL, 

X 

CON  T 
SIGNAL 
NO.  1 

CONT 
SIGNAL 
NO.  2 

1 

M400 

TACOUT 

TACCAR 

02 

P 

DC 

TEST 

2.55 

VOLT 

5 

M340 

M345 

262 

M310 

XMTPLS 

TACCAR 

02 

S 

LPV 

TEST 

10 

VOLT 

5 

M320 

262 

M315 

DSCOUT 

TACCAR 

02 

S 

DC 

TEST 

0.5 

-0.5 

VOLT 

N/A 

M320 

262 

M320 

CVSOUT 

TACCAR 

02 

S 

DC 

TEST 

3 

VOLT 

5 

M330 

M315 

26! 

M330 

TACCO 

TACCAR 

02 

S 

DC 

TEST 

3 

VOLT 

5 

M340 

M345 

26! 

M340 

SUMC 

TACCAR 

02 

S 

IF 

TEST 

2.55 

VOLT 

N/A 

M350 

M355 

26! 

M345 

DIFFC 

TACCAR 

02 

S 

IF 

TEST 

2.55 

VOLT 

N/A 

M350 

M355 

28 

M3S0 

SUMF 

TACCAR 

02 

S 

IF 

TEST 

2.55 

VOLT 

N/A 

M360 

M365 

28 

M35S 

DIFFF 

TACCAR 

02 

S 

IF 

TEST 

2.55 

VOLT 

N/A 

M360 

M365 

28 

M360 

SUMV 

TACCAR 

02 

S 

IF 

TEST 

2.55 

VOLT 

N/A 

M3  70 

S410 

28 

M36S 

DIFFV 

TACCAR 

02 

S 

IF 

TEST 

2.55 

VOLT 

N/A 

M370 

S410 

28 

M3  70 

SUMO 

_ 

TACCAR 

02 

S 

ANT 

TEST 

-50 

DBM 

N/A 

S400 

M310 

28 

Frs  *  2629  x  10-6  FAILURI 

NOTE: 

II)  SENSOFI  NOT  REQUIRED  SINCE  PERFORMANCE  MONITOR  SENSOR  ALREADY  EXISTS  FOR  TRANSMITTER  AS  PART  OF  ADS-125. 

(2)  RANGE  AND  TACCAR  FUNCTIONS  HAVE  CONSOLE  CRT*  AND  INDICATORS  WHICH  PROVIDE  INTRINSIC  BIT.  EXTRINSIC  BIT,  IN  THE  FORM  OF  SEK 
TO  ACHIEVE  THE  NECESSARY  EFFECTIVENESS, 


2181-00SW 


I 

AMPLITUDE 

UNIT 

TOL, 

% 

CONT 
SIGNAL 
NO.  1 

• 

frp 

x  10® 

TEST  7 

PM  INT 

PM  EXT 

DETECT 

ISOLATE 

Of 

% 

TIME, 

MS 

SAMP 

RATE 

COST, 

$K 

SENSOR 

EVAL 

WORTH 

(ISO). 

xIO® 

WORTH 

(DET), 

X  lO® 

NOTES 

VOLT 

5 

M340 

M345 

2629 

y 

nr 

Y 

Y 

Y 

85 

100 

rr~ 

4.0 

THRESH. 

L 

TBD 

TBD 

NOTE  (2) 

1 

VOLT 

5 

M320 

2629 

Y 

Y 

Y 

Y 

Y 

85 

3.0 

300 

5.0 

THRESH. 

L 

TBD 

TBD 

3 

VOLT 

N/A 

M320 

2629 

Y 

Y 

Y 

Y 

Y 

85 

3.0 

300 

2.5 

THRESH. 

L 

TBD 

TBD 

B 

VOLT 

5 

M330 

M315 

2629 

Y 

Y 

Y 

Y 

Y 

85 

10 

C 

3.0 

THRESH. 

L 

TBD 

TBD 

1 

VOLT 

5 

M340 

M345 

2629 

Y 

Y 

Y 

Y 

Y 

85 

3.0 

300 

2.5 

THRESH. 

L 

TBD 

TBD 

■ 

VOLT 

N/A 

M350 

M355 

2629 

Y 

Y 

V 

Y 

Y 

85 

1.0 

C 

2.5 

THRESH. 

L 

TBD 

TBD 

. 

VOLT 

N/A 

M350 

M355 

2629 

Y 

Y 

Y 

Y 

Y 

85 

1.0 

c 

2.5 

THRESH. 

L 

TBD 

TBD 

1 

VOLT 

N/A 

M360 

M365 

2629 

Y 

Y 

Y 

Y 

Y 

85 

1.0 

300 

2.5 

THRESH. 

L 

TBD 

TBD 

■ 

VOLT 

N/A 

M360 

M365 

2629 

Y 

Y 

Y 

Y 

Y 

85 

1.0 

300 

2.5 

THRESH. 

L 

TBD 

TBD 

1 

VOLT 

N/A 

M3  70 

S410 

2629 

Y 

Y 

Y 

Y 

Y 

85 

1.0 

300 

4.26 

THRESH. 

L 

TBD 

TBD 

a 

VOLT 

N/A 

M3  70 

S410 

2629 

Y 

Y 

Y 

Y 

Y 

85 

1.0 

300 

4.25 

THRESH. 

L 

TBD 

TBD 

-50 

DBM 

N/A 

S400 

M3I0 

2629 

N 

Y 

N 

Y 

Y 

85 

1.0 

300 

0 

- 

- 

TBD 

TBD 

SEE  NOTE  (1) 

Frs  =  2629  X  10®  FAILURES/HR  TOTAL  COST  =  J35.5K 


•HITTER  AS  PART  OF  ADS-125. 

IINSIC  BIT.  EXTRINSIC  BIT.  IN  THE  FORM  OF  SENSORS  AND  TEST  TARGETS  PROVIDE  THE  ADDITIONAL  BIT  REQUIRED 


Fig.  C-3  Preliminary  Output  Signal  Matrix 
(TACCAR  Function) 


V. 
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(A)  review  the  subsystem  maintenance  concept /maintenance  plan 

(B)  determine  the  output  signals  to  be  measured 

(C)  develop  a  PM /BIT  architecture 

(D)  estimate  PM /BIT  effectiveness 

(E)  estimate  Mtt 

(F)  estimate  PM/BIT  cost 

(G)  adjust  initial  PM /BIT  design  concept 

(H)  adjust  PM/BIT  design  concept  effectiveness 

(I)  adjust  M^. 

Step  3A  Review  of  the  Maintenance  Concept /Plan 

A  review  of  the  preliminary  subsystem  maintenance  concept /plan  for  the 
ARPS,  derived  from  the  Grumman  Design  Specification  for  the  APS-125  Radar, 
shows: 

•  level  of  maintenance  is  flight  line 

•  level  of  fault  isolation  is  to  the  LRU 

•  test  concept  -  BIT  and  PM  fault  detection  of  97 . %  with  an  Mct  of  30 
minutes;  the  Mtt  target  is  3  minutes 

•  external  test  equipment  will  not  be  required 

•  false  alarm  rate  =  1%  of  total  subsystem  failure  rate 

•  fault  isolation  will  be  done  automatically  unless  an  "on  demand,"  manu¬ 
ally  initiated  test  mode  offers  significant  advantages 

•  fault  criteria  -  as  a  minimum,  the  subsystem  will  provide  failure  indica¬ 
tions  with  the  characteristics  defined  in  Fig.  C-7  (note  that  T  =  failure 
criteria  for  TACCAR  function,  and  R  =  failure  criteria  for  Range 
function) . 

Step  3B  Initial  Determination  of  the  Output  Signals  to  be  Measured 

The  primary  output  signals  have  been  designated  on  the  signal  matrices . 
/or  the  TACCAR  function,  the  primary  output  signal  is  the  "TACOUT"  signal. 
For  the  Range  function,  the  primary  output  signal  is  the  "RNG013"  signal.  The 


2x4 


FAILURE  INDICATION 

FAILURE  INDICATIONS  AND  CRITERIA 

INTERFACE  FAULT  (R) 

LOSS  OF  DATA,  CLOCK,  OR  DATA  BUS  TRANSMISSION  BETWEEN 
LRUS. 

DIGITAL  DATA  COMPARATOR 

POWER  SUPPLY  (T,  R) 

LOSS  OR  DEGRADATION  OF  POWER  SUPPLY. 

WIDE  BAND  NO.  1  (T,  R) 

LOSS  OR  DEGRADATION  OF  SIDE  LOBE  CANCELER  NO.  1. 

WIDE  BAND  NO.  2  (T.  R) 

LOSS  OR  DEGRADATION  OF  SIDE  LOBE  CANCELER  NO.  2. 

NARROW  BAND  (T,  R) 

30  Db  DEGRADATION. 

CANCELED  VIDEO  (R) 

LOSS  OR  DEGRADATION  OF  CIRCUIT  THAT  AFFECTS  THE  DIGITA^ 
SIGNAL  CONVERTER  INPUTS  BUT  NOT  CANCELED  VIDEO. 

DIGITAL  SIGNAL  CONVERTER 
nEGRADED (R) 

DEGRADATION  OF  DIGITAL  SIGNAL  CONVERTER  GREATER  THAN 

3  Db. 

DIGITAL  SIGNAL  CONVERTER 

AND/OR  DATA-PROCESSOR 

OVERHEAT (R) 

OVERTEMPERATURE. 

PULE^  COMPRESSED  VIDEO  (R) 

LOSS  OR  DEGRADATION  OF  CIRCUIT  THAT  AFFECTS  DIGITAL 
SIGNAL  CONVERTER  INPUTS  CANCELED  VIDEO  BUT  NOT  PULSE 
COMPRESSED  VIDEO. 

LONG  PULSE  COMPRESSED 

VIDEO  tT.RI 

LOSS  OR  DEGRADATION  OF  CIRCUIT  THAT  AFFECTS  DIGITAL 
SIGNAL  CONVERTER  INPUTS,  CANCELED  VIDEO  &  PULSE  COM¬ 
PRESSED  VIDEO,  BUT  NOT  LONG  PULSE  VIDEO. 

DETECTOR  PROCESSOR 

FAUI  T  (R) 

LOSS  OR  DEGRADATION  OF  CIRCUIT  THAT  AFFECTS  DETECTOR 
PROCESSOR. 

RANGE  (R) 

LOSS  OR  DEGRADATION  OF  DETECTOR  PROCESSOR  RANGE. 

VELOCITY  (R) 

LOSS  OR  DEGRADATION  OF  DETECTOR  PROCESSOR  VELOCITY. 

0719-035 

Fig.  C-7  Minimum  Fault  Indications  and  Characteristics 


Range  function  is  tested  automatically,  on-line,  during  an  inactive  period  of 
the  antenna  sweep.  To  test  the  TACCAR  function,  the  operator  initiates  the 
TACCAR  test  mode  via  the  Radar  Control.  Signals  were  designated  as  follows: 

•  Initial  Designation  of  Signals  Measured  for  BIT  Fault  Detection  -  Since 


"TACOUT"  and  "RNG013"  are  the  only  two  primary  outputs  in  this  il¬ 
lustration,  and  since  they  are  needed  for  performance  monitoring,  they 
will  not  be  traded  off.  However,  in  order  to  illustrate  the  methodology, 
the  worth  of  sensing  each  output  is  calculated. 

In  determining  the  worth  of  fault-detecting  these  two  outputs,  the 
following  equation  is  solved: 


where  W  ,  =  worth  of  each  primary  output  signal  to  be  tested,  F  =  fail 
Q  _6  rP 

ure  rate  (xlO  hours)  of  path  leading  to  that  primary  output  (obtained 

from  signal  matrices),  Q^.  =  measurement  quality  factor  (average),  and 

Cp  =  estimated  production  cost  of  PM/BIT  (from  signal  matrices). 

For  the  Range  function: 

Frp=  3638  x  10~6 

Cp  =  $105,500 


Qj.  =  0.90  (average) 


So  that 


3638  x  0.90  x  10~ 
105,500 


-  0.03  x  10 


For  the  TACCAR  function: 


Wd  is  indeterminately  high  because  the  path  has  intrinsic  fault  detec 
tion.  If  the  TACCAR  function  was  not  working,  excessive  clutter 
would  result,  enabling  the  operator  to  see  this  in  his  video  display. 
Because  of  this,  C  as  0. 


For  a  completed  BIT  design,  the  worth  factors  measuring  other  primary 
outputs  would  be  combined  with  the  two  that  are  shown  and  ranked  in 
order  of  decreasing  worth.  This  ranking  would  be  used, in  later  trade¬ 
offs. 

•  Initial  Designation  of  Signals  for  Fault  Isolation  -  The  next  step  in  the 
design  process  is  to  designate  sensors  on  all  the  secondary  outputs  and 
compute  their  worth.  Subsequent  trade-offs  may  see  the  elimination  of 
those  with  least  worth  (W^).  The  computed  worth  for  these  trade-offs 
is  given  in  Figs.  C-8  and  C-9.  The  relationships  between  the  signal 
outputs,  as  derived  from  the  signal  matrices,  and  the  uncertainty  re¬ 
solved  by  their  sensors,  are  shown.  Failure  rates  are  obtained  from 
the  functional  flow  diagrams.  However,  before  the  worth  of  the  sensors 
in  the  TACCAR  functional  path  can  be  computed ,  the  feedback  loop  was 
broken  at  the  M330  output. 

The  Q^'s  shown  considered  the  use  of  software  diagnostics  for  the  digi¬ 
tal  units,  with  Q^.  estimated  as  95%,  and  hardware  sensors  for  the  re¬ 
maining  LRUs  with  estimated  as  85%. 

Fault  isolation  data  are  displayed  on  the  Performance  Indicator  and  in¬ 
clude  information  from  sensors  monitoring  the  sum  and  difference  fre¬ 
quencies,  Aux  1,  2,  3,  4,  wide  band  and  narrow  band  correlators,  and 
UHF  amplifier. 

There  is  another  group  of  faults  sensed  by  hardwired  sensors.  These 
faults  are  clock  failure,  power  supply  malfunction,  overheat,  and  de¬ 
graded  performance.  These  faults  are  also  displayed  on  the  Perfor¬ 
mance  Indicator  and  are  transmitted  to  the  IFPM  where  they  are  used 
for  fault  isolation. 

The  worth  of  each  sensor  (whether  hardware  or  software)  is  computed 
as: 


Uf  x  Qf 


where  W.  =  worth  of  each  secondary  output  to  be  tested,  =  uncertain¬ 
ty  resolved  in  terms  of  relative  failure  rate  (reference  paragraph 
4. 4. 3. 3),  Qf  =  measurement  quality  factor  of  sensor,  and  Cp  =  esti¬ 
mated  production  cost  of  sensor  (from  signal  matrices). 
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SIGNAL 

OUTPUT 

NO. 

£  NORMALIZED 
FAILURE  RATES, 

P< 

M218,  M218 

0.23 

M215.  M225 

0.41 

M217,  M219 

0.18 

M223,  M221 

0.05 

M210.M220 

0.74 

M227,  M228,  M229 

0.06 

M200 

1.0 

RELATIVE 

UNCERTAINTY 

RESOLVED, 

U. 


5,000 

7,000 

5,000 

3.500 

25,000 

15,000 

40,000 


$106,500 


119  * lO"* 


30x10"® 


Fig.  C-8  Ranking  of  Seniors  For  Range  Function 


SIGNAL 

OUTPUT 

NO. 


M370 

M350,  M365 
M340,  M345 
M360,  M366 
M310.M315 
M320 

M330,  M400 


£  NORMALIZED 
FAILURE  RATES, 


RELATIVE 

UNCERTAINTY 

RESOLVED, 


1684-005  AW 


The  results  are  shown  in  Figs.  C-8  and  C-9. 


Step  3C  Development  of  a  PM /BIT  Architecture 

The  next  task  is  to  formulate  a  PM /BIT  architecture  that  will  satisfy  the' 
design  requirements  and  stay  within  the  target  cost. 

The  ARPS  has  an  architecture  utilizing  both  a  centralized  and  decentral¬ 
ized  PM /BIT  design.  Each  ARPS  LRU  contains  both  the  sensor  and  evaluator, 
and  transmits  a  fault  report  via  the  data  bus  to  the  Performance  Indicator. 

Fault  reports  are  also  sent  to  the  IFPM  for  display  to  the  system  operator. 
Figures  C-10  and  C-ll  illustrate  the  PM /BIT  architecture.  Note  that  the 
TACCAR  feedback  loop  can  be  opened  by  means  of  a  manually  initiated  control 
designed  to  facilitate  testing. 

Hardwired  BIT  sensors  of  the  following  characteristics  are  chosen: 

•  Servo /Gate  -  This  sensor  is  part  of  the  control  voltage  simulator.  It 
detects  a  follow-up  error  of  less  than  8°  or  greater  than  15°  and  also 
detects  the  presence  of  a  TACCAR  clutter  gate 

•  Sync  Test  -  This  sensor  (in  the  Pulse  Generator)  detects  the  presence 
of  a  fault  if  the  interpulse  period  is  in  error  by  ±20%.  It  also  detects 
the  absence  of  the  data  bus  clock 

•  AFC  -  This  sensor  (located  in  the  Control  Voltage  Simulator)  detects 
incremental  change  in  frequency  of  the  Pulse  Generator  outputs  in  ex¬ 
cess  of  20  Hz  at  15  MHz 

•  LVPS  Test  -  This  sensor  detects  loss  of  Power  Supply  regulation 

•  DSC  Power  -  This  sensor  detects  overvoltage  greater  than  10%,  over 
current  greater  than  125%  of  maximum  load,  and  an  overheat  condition 
greater  than  85°C . 

The  quality  factors  of  these  hardwired  sensors  are  estimated  to  be  85%. 

The  Detector-Processor,  Digital  Data  Comparator,  and  Digital  Signal  Con¬ 
verter  are  tested  exclusively  through  the  use  of  software  BIT.  Data  Processor 
monitoring  is  done  using  stored  test  vectors  or  test  targets.  Test  targets  are 
injected  at  ranges  from  0  to  19  miles  and  greater  than  the  maximum  active  range 
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DAT A  BUS 


11  TACCAR  Function  Proposed  PM/BIT  Output  Configuration 


of  240  miles.  Since  no  real  targets  are  processed  in  these  ranges,  target  re¬ 
ports  are  automatically  inhibited. 

If  either  the  Detector  Processor,  Digital  Data  Comparator,  or  the  Digital 
Signal  Converter  are  faulty,  a  BIT  indication  is  transmitted  to  the  Performance 
Indicator  and  IFPM  via  the  data  bus. 

Since  the  Detector-Processor  contains  a  computer,  it  is  practical  to  utilize 
diagnostics  or  test  targets  stored  in  PROMs  for  BIT  functions.  This  implementa¬ 
tion  is  very  cost-effective  since  little  new  hardware  is  required.  Also,  the  sub¬ 
system  is  amenable  to  this  approach  because  ample  "dead  time"  exists  for  on¬ 
line  testing  during  the  inactive  ranges.  The  sampling  time  is  approximately  1.2 
seconds  to  process  one  test  target,  or  15.6  seconds  for  the  required  13  test  tar¬ 
gets.  This  provides  a  complete  test  of  the  Detector  Processor,  with  a  quality 
factor  estimated  as  95%. 

The  APS- 125  and  ARPS  utilize  a  data  bus  for  control  and  fault  reporting. 
Evaluation  is  done  locally  in  each  LRU.  Control  information  is  transmitted  from 
the  Radar  Set  Control  to  the  various  LRUs,  and  fault  reports  from  individual 
LRUs  are  received  by  the  Performance  Indicator. 

Figure  C-12  shows  the  data  bus  control  and  fault  reporting  system.  The 
Performance  Indicator  is  used  to  display  fault  reports.  Figure  C-13  is  a  block 
diagram  of  the  assembly. 

The  following  guidelines  were  used  in  designing  the  LRU : 

•  particular  attention  was  paid  to  the  reliability  of  the  display  itself  to 
ensure  that  failure  of  the  display  circuitry  does  not  mask  a  function 
failure  or  erroneously  indicate  a  failure 

•  the  information  content  of  the  display  was  no  more  than  the  observer 
requires 

•  use  of  the  display  for  presenting  maintenance  information  was  considered 
in  establishing  display  requirements 

•  the  prominence  and  placement  of  the  display  is  consistent  with  the  im¬ 
portance  of  the  information  it  provides.  In  this  regard,  displays  of 
other  than  radar  functions  were  taken  into  account. 
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(15  CONSECUTIVE  FAULTS) 

BUS  CLK  J  | 


OATA  BUS- 

NO'N  80S  OATA  - 
(AFC,  LVPS.  ETC) 
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FILTER 


FLTR  DATA 
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Fig.  C-13  Performance  Indicator  Signal  Procetsing  Circuitry,  Block  Diagram 


r 

i 


¥ 


While  the  assembly  can  be  viewed  during  flight,  its  primary  function  is  to 
assist  the  maintenance  technician  in  ground  testing.  LRU  faults  automatically 
appear  on  front  panel  lights.  Additional  capability  exists  by  fault  isolation 
operator  intervention. 

Step  3D  Initial  Estimation  of  PM /BIT  Effectiveness 

BIT  Effectiveness  is  now  calculated  from  the  following  equation  (from  para¬ 
graph  4.4.5): 

g  _  _ Its - 

T~  ^s  +  Frsx(l-Q)x0.5(N+l) 

where  Fr„  is  the  summation  of  all  failure  rates  in  the  signal  matrices,  Q  is  the 
sensor  quality  factor,  and  N  is  the  average  number  of  LRUs  in  the  function 
paths  of  the  ARPS. 

Q  =  0.875  (an  average  of  Range  and  TACCAR  functions)  and  N  =  7.  Effec¬ 
tiveness  is: 

F _ 1 - 

“T  “  1  +  ( 1-Q)  x  0.5  x  (7+1) 

=  1  +  (0.125  x  4)  =  67% 

This  approximation  of  ET  is  less  than  the  requirement.  This  indicates  that 
all  designated  sensors  must  remain  and  none  can  be  traded  off.  In  fact,  mea¬ 
surement  quality  factors  must  be  increased.  Note  that  the  effect  of  false  alarms 
has  not  been  included.  This  will  further  decrease  BIT  effectiveness  in  the  final 
calculation . 

Step  3E  Initial  Estimate  of  Mean  Test  Time 

The  requirement  is  3  minutes.  The  initial  estimate  of  Mtt  is  calculated 
using  the  processing  times  shown  in  Fig.  C-14. 
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Processing  Time  x  Frp 

Processing  Time  (2Mtt)  x  Frp 
Overall  Acquisition  Time 


16,507  x  10" 3  x  3638  x  IQ' 
60  x  10  3  sec  (Range) 

117  x  10"3  x  2629  x  10"6 
0.3  x  10~3  sec  (TACCAR) 
2  (Frp  x  ®^tt) 

F 

rrs 

60  x  10~3  +  0.3  x  10~3 
6267  x  10-6 
9. 6  sec 


Performance  Indicator  Processing  Time  =  2.5  sec 

IFPM  Processing  Time  =  2.5  sec 

M  Processing  Time 

U  (Total)  =14.6  sec 


RANGE 

TACCAR 

LRU 

PROC  TIME 
iRf,).  MS 

»=R. 

X  10-* 

PROC  TIME 
(Mff),  MS 

FrU 

xio-« 

receiver-converter 

1.0 

135 

1.0 

186 

COMPAR ATOR-F ILTER 

1.0 

480 

1.0 

480 

DUAL  PULSE  ATTENUATOR- 
COMPRESSOR 

1.0 

173 

1.0 

173 

PULSE  GENERATOR 

1.0 

227 

227 

DIGITAL  DATA  COMPARATOR 

900 

668 

100 

350 

DIGITAL  SIGNAL  CONVERTER 

3.0 

1193 

- 

- 

DETECTOR  PROCESSOR 

15,600* 

712 

- 

- 

TRANSMITTER 

- 

1.0 

1100 

CONTROL  VOLTAGE  SIMULATOR 

- 

- 

10.0 

114 

TOTALS 

16,507 

3638 

117 

2629 

•13  TEST  TARGETS  AT  1200  MS  EACH. 

0719-O42WK 

Fig.  C  14  LRU  Processing  Tima* 
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Step  3F  PM/BIT  Cost  Estimate 


i 


i 


To  estimate  the  production  costs  of  PM /BIT  for  the  Range  and  TACCAR 
functions,  the  cost  entries  shown  on  the  matrices  are  added. 

For  the  TACCAR  function:  PM/BIT  =  $35,500;  for  the  Range  function: 
PM/BIT  =  $105,500. 

Adding  the  costs  of  the  Performance  Indicator  and  the  Radar  Set  Control 
to  this,  we  arrive  at  the  following: 

Performance  Indicator  =  $  43,600 

Radar  Set  Control  =  $  4,600  (PM /BIT  portion  only) 

TACCAR  PM/BIT  =$  35,500 

Range  PM/BIT  =  $  105,500 

$  189,200 

These  costs  represent  6.8%  of  the  overall  ARPS  production  costs  ($2.8M). 
From  Fig.  3-4,  the  cost  target  is  20%  for  digital  systems  (some  analog). 

Step  3G  Adjustment  of  PM /BIT  Design  Concept 

The  initial  estimates  of  PM /BIT  effectiveness,  M^,  and  cost  are  compared 
to  the  like  parameters  of  the  design  specification  in  Fig.  C-15.  Note  that  E^, 
must  now  be  improved  without  exceeding  the  cost  envelope. 

Step  3H  Adjustment  of  Design  Concept  Effectiveness  Parameter 

E^,  will  now  be  computed  in  terms  of  valid  and  invalid  maintenance  actions. 


PARAMETER 

REQUIREMENTS 

INITIAL  ESTIMATES 

et 

97,5% 

67% 

180  SEC 

14.6  SEC 

COST  (%  OF  TOTAL 
COST) 

20% 

6.8% 

0719-043WR 

Fig.  C-15  Comparison  of  Parameters  to  the  Design  Specification 
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From  paragraph  4.4.5  of  the  methodology,  the  rate  of  invalid  maintenance 
actions  is  F  x  (1-Q)  x  0.5  (N+l). 

Where  for  the  ARPS  Np  =  7,  Frp  =  3638  x  10_6  (Range),  Frp  =  2629  x  10_6 
(TACCAR),  and  =  85%  to  95%  (from  the  signal  matrices). 

For  a  given  primary  output  signal  (Range  and  TACCAR  functions),  the 
rat  :  of  invalid  maintenance  actions  is: 

MArid  =  Frp  x  (1_Qf)  x  °‘5  (N  0 

Where  F  -  failure  rate  of  signal  path,  Q^.  =  quality  factor  of  the  fault  detection 
sensors  (average),  and  N  =  number  of  LRUs  in  the  path  from  input  to  primary 
output . 

_  6 

For  the  Range  function,  where  N  =  7,  F  =  3638  x  10  ,  and  Quaver- 

age)  =  0.90: 

MA  .  ,  =  3638  x  10' 6  x  (1-0.90)  x  4 
rid 

=  1455  x  10~6 

This  results  in  an  (RNGE) 


F  +  MA  .  ,  3638  +  1455 

rp  rid 


=  0.71 


For  the  TACCAR  function,  where  N  =  7,  F  =  2629  x  10  ,  and  Q,  (aver- 

rp  i 

age)  =  0.85: 

MA  .  ,  =  2629  x  10~6  x  (1-0.85)  x  4 
rid 

=  1577  x  10"6 

Resulting  in  an  5T(-pAC)  °^: 


2629  +  1577 


=  0.63 


For  both  functions,  ET  =  626?  +  1455  +  1577  =  °'67 


An  E,p  ot  67%,  caused  solely  by  undetected  failures,  obviates  the  need  to 
calculate  the  invalid  maintenance  action  rate  contributed  by  improper  fault 
isolation. 


The  concept  is  therefore  adjusted  by  placing  a  fault  detection  sensor  in 
each  LRU  and  making  all  of  them  independent  of  the  inputs  from  preceding 
LRUs.  BIT  effectiveness  is  improved.  Stimulus  injection  and/or  measurement 
of  the  output  lines  is  done  automatically,  with  N  =  1.  Fault  isolation  is  there¬ 
fore  to  the  LRU  containing  the  sensor. 

Figures  C-16  and  C-17  list  the  invalid  maintenance  action  rates, 

and  °f  the  Range  and  TACCAR  signal  paths,  respectively.  N  =  1 

and  F  .  is  the  failure  rate  of  each  LRU  and  the  false  alarm  rate  (FA)  is  1%. 
n 

For  both  functions  (from  paragraph  4.4.9): 

F 

I*S 

BIT  Etfectiveness ,  ET  ,  =  - 

F  +  MA,  .  +  MA.  .  ...  +  FA  (F  J 

rs  (rid)l  (nd)2  rs' 

6267 

6267  +  289  +  395  +  63 
=  0.90 

Step  31  Adjustment  of  Design  Concept  Mtt  Parameter 

Since  reliability  and  maintainability  considerations,  coupled  with  the  unique 
mechanical  configurations  of  the  LRUs,  are  the  driving  forces  in  ARPS,  PM/BIT 
processing  times  have  negligible  impact  on  Mfit .  For  this  design,  the  Mtt  will  be 
evaluated.  For  the  two  ARPS  functions  selected  for  this  illustration,  14.6 
seconds  appear  reasonable  as  an  average.  We  can  proceed  now  to  the  next  step. 

Step  3J  System  Effectiveness  and  10tt 

AGE  is  not  used  for  ARPS,  hence  this  design  step  is  not  applicable. 

Step  4  UPDATED  ESTIMATE  OF  FAILURE  RATES  AND  MEASUREMENT  QUALITY 

Accuracy  of  the  failure  rates  was  re-examined,  emphasizing  LRUs  with 
lower  Qj.  sensors.  The  of  each  sensor  was  also  re-evaluated  to  see  that  it  was 
as  realistic  as  possible. 

Step  4A  Updated  Reliability  Estimates 

The  failure  rates  used  up  to  this  point  were  extracted  from  the  E-2C  Main¬ 
tenance  Engineering  Analysis  Summary  Sheets,  dated  December  13,  1978.  MIL- 
HDBK-217B  methods  were  employed  therein  and  the  failure  rates  represent  the 
best  predictions  for  an  initial  design. 
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MA(rld)  1 

LRU 

(xIO*) 

RECEIVER-CONVERTER 

185 

0.86 

28 

COMPARATOR  -FI  LTER 

480 

0.85 

72 

DUAL  PULSE  ATTENUATOR- 

173 

0.86 

26 

COMPRESSOR 

PULSE  GENERATOR 

227 

0.85 

34 

DIGITAL  DATA 

668 

0.95 

33 

COMPARATOR 

DIGITAL  SIGNAL 

1193 

0.95 

60 

CONVERTER 

OETECTOR— PROCESSOR 

712 

0.95 

36 

^  FRI-3638  x  10'6 

^  MA(rid)  1  -  289 

ETinwr;cl  « 

.  3638(100) 

93% 

Fp,  +Tma  3638  +  289 

Rl  +iMA(fid|  , 

21 81-008W 

Fig.  C-16  Maintenance  Action  Rate  Due  to  Undetected 
Failure*  for  the  Renge  Function 
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FRI 

(x  10-*) 

■ 

MA(rW)2 
(x  lO"6) 

PULSE  GENERATOR 

227 

0.85 

34 

DIGITAL  DATA  COMPARATOR 

350 

0.85 

63 

DUAL  PULSE  ATTENUATOR  - 
COMPRESSOR 

173 

0.85 

26 

COMPARATOR  -  FILTER 

480 

0.85 

72 

RECEIVER  -  CONVERTER 

186 

0.85 

28 

CONTROL  VOLTAGE 

SIMULATOR 

114 

0.85 

17 

TRANSMITTER 

1100 

0.85 

165 

2  FR|  -  2629  x  10-6 

ZMA<rld>2-396 

p  .  2629  (100)  . 

T(TAC)  2629  +  395 

2181 -009W 

87% 

TTTW  T  *  T  Iir»TW'T4  iT»] 


forth*  TACCAR 
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For  the  ARPS,  however,  initial  3M  data  has  started  to  flow  back  from  the 
field.  It  shows  that  the  observed  (operational)  failure  rates  are  about  4.5 
times  the  predicted.  The  ARPS  sample  is  still  small  and  the  ratio  may  not  be 
accurate.  A  point  of  interest,  however,  is  that  it  is  consistent  with  the  dis¬ 
cussion  of  paragraph  1.6.7  of  Section  1. 

At  this  stage  in  the  BIT  design  process,  the  designer  must  rely  on  the 
predicted  failure  rates  derived  by  the  reliability  engineer.  For  the  ARPS 
example,  these  are  the  numbers  that  will  be  used  in  developing  the  BIT  design. 

Step  4B  Updated  Measurement  Quality  Estimates 

A  summary  is  presented  in  Figs.  C-18  and  C-19  of  the  quality  factors, 
failure  rates,  primary  vs  secondary  outputs,  Mtt's  and  costs  for  each  LRU  used 
in  the  Range  and  T  AC  CAR  functions. 

Step  5  Final  Calculation  of  PM /BIT  Performance  and  Cost  Parameters 


In  this  final  step,  ,  Mtt,  and  the  target  production  costs  are  finalized 
and  compared  with  the  same  values  in  the  subsystem  design  specificiation . 

Once  this  is  done  we  see  that  of  the  three  parameters,  ET  is  out  of  speci¬ 
fication.  In  considering  ET ,  the  BIT  effectiveness  is  90%  as  compared  to  the 
specified  97.5%. 

Step  5A  Calculated  Effectiveness  is  Insufficient ,  While  and  Cost  are  Acceptable 


We  must  establish  which  LRU  quality  factors  must  be  improved.  For  the 
Range  function  there  are  several  sensors  of  analog  design  whose  quality  factors 
depend  on  component  tolerance  and  comprehensive  circuit  design.  By  tighten¬ 
ing  these  tolerances,  the  initial  estimate  of  Q^.  =  0.85  can  be  increased  to  0.90. 

Similarly  for  the  TACCAR  function,  the  of  the  analog  sensors  can  also 
be  increased  from  0.85  to  0.90.  In  addition,  since  the  Digital  Data  Comparator 
is  primarily  digital,  the  of  its  sensor  can  increase  from  0.85  to  0.95  by  ex¬ 
pansion  of  the  software  diagnostics.  The  transmitter  sensor  Q^.  can  also  be  in¬ 
creased  to  0.95. 

Repeating  step  3H ,  the  number  of  invalid  maintenance  actions  is  calculated 
for  the  Range  and  TACCAR  functions,  using  the  revised  Q^'s.  The  results  are 
tabulated  in  Figs.  C-20  and  C-21. 


LRU 
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xIO* 

Qf 

TARGET 

COST 

$ 

PRIMARY/ 

SECOND¬ 

ARY 

SEC 

RECEIVER-CONVERTER 
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0.85 

8500 

P 

6.0 

COMPARATOR  -F 1 LTER 

480 

0.85 
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P 

5.0 

DUAL  PULSE  ATTENUATOR- 

173 

0.85 

5000 

P 

5.0 

COMPRESSOR 

DIGITAL  DATA  COMPARATOR 

668 

0.95 

7000 

P 

5.9 

DIGITAL  SIGNAL  CONVERTER 

1193 

0.95 

25000 

P 

5.0 

DETECTOR  PROCESSOR 

712 

0.95 

40000 

P 

20.0 

PULSE  GENERATOR 

227 

0.85 

15000 

P 

5.0 

RANGE  BIT  COSTS  -  $105,500 

•THESE  NUMBERS  ARE. DERI  VED  FROM  STEP  3E  AND  INCLUDE  THE  TOTAL  6  SECOND  PROCESSING  TIME 
OF  THE  PERFORMANCE  INDICATOR  AND  IFPM. 
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Fig.  C-18  Summary  of  Updated  Measurement  Duality  Estimates,  Range  Function 
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5.0 
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3000 

P 

5.0 

PULSE  GENERATOR 

0719-04  7WR 

227 

0.85 

7500 

P 

5.0 

TACCAR  BIT  COSTS  =  $35,500 

•THESE  NUMBERS  ARE  DERIVED  FROM  STEP  3E  AND  INCLUDE  THE  TOTAL  5  SECOND  PROCESSING 
TIME  OF  THE  PERFORMANCE  INDICATOR  AND  IFPM. 


Fig.  C-19  Summary  of  Updated  Measurement  Quality  Estimates,  TACCAR  Function 
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Fig.  C-20  Revised  Maintenance  Action  Rate  Due  to  Undetected 
Failuret.for  the  Range  Function 
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Fig.  021  Revised  Maintenance  Action  Rate  Due  to  Undetected 
Failures  for  the  TACCAR  Function 
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For  both  functions  shown  in  Figs.  C-20  and  C-21, 

BIT  Effectiveness,  ET  =  _ 6267 _ 

1  6267  +  236  +  183  +  0.01  (6267)  “ 

This  would  then  be  the  maximum  E^  that  can  be  obtained  from  the  BIT 
design  as  conceived  by  our  illustration,  since  the  revised  sensor  Q^'s  are  the  best 
that  can  be  achieved  within  reasonable  bounds  of  cost  and  availability. 

The  specified  PM /BIT  parameters  and  costs  to  be  used  for  the  LRU  design 
phase  are  listed  in  Fig.  C-22. 

The  costs  for  each  function  shown  in  Fig.  C-22  have  been  combined.  BIT 
costs,  therefore,  have  increased  from  an  initial  estimate  of  $189,200  or  6.8%  of 
the  total  cost,  to  $250,200  or  8.9%.  These  costs  are  within  the  allowable  cost 
envelope  and  will  be  specified  to  the  LRU  designer.  The  completed  signal  ma¬ 
trices  are  shown  in  Figs.  C-23  and  C-24. 
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L 
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0.037 
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N/A 

M216 

M218 

M227 

334 

Y 

Y 

Y 

Y 

Y 

95 

900 

300 

8.5 

COMPAR 

L 

0.037 

0.037 

VOLT 

N/A 

M217 

M219 

86 

V 

Y 

Y 

Y 

Y 

90 

1.0 

C 

5.0 

THRESH. 

L 

0.015 

0.015 

VOLT 

N/A 

M217 

M219 

87 

Y 

Y 

Y 

Y 

Y 

90 

1.0 

C 

5.0 

THRESH. 

L 

0.016 

0.016 

VOLT 

5 

M221 

M223 

240 

Y 

Y 

Y 

Y 

Y 

90 

1.0 

300 

5.0 

THRESH. 

L 

0.043 

0.043 

VOLT 

5 

M221 

M223 

240 

Y 

Y 

Y 

Y 

Y 

90 

1.0 

300 

5.0 

THRESH. 

L 

0.043 

0.043 

VOLT 

5 

S100 

S110 

92 

Y 

Y 

Y 

Y 

Y 

90 

1.0 

300 

8.5 

THRESH. 

L 

0.010 

0.010 

VOLT 

5 

S100 

S110 

93 

Y 

Y 

Y 

Y 

Y 

90 

1.0 

300 

8.5 

THRESH. 

L 

0.010 

0.010 

VOLT 

5 

S120 

75 

Y 

Y 

Y 

Y 

Y 

90 

1.0 

C 

5.0 

THRESH. 

L 

0.014 

0.014 

VOLT 

5 

SI  20 

76 

Y 

Y 

Y 

Y 

Y 

90 

1.0 

C 

5.0 

THRESH. 

L 

0.014 

0.014 

VOLT 

5 

SI  20 

76 

Y 

Y 

Y 

Y 

Y 

90 

1.0 

c 

5.0 

THRESH. 

L 

0.014 

0.014 

NOTES 


Frp  -  3638  x  10"®  FAILURES/HR 


TOTAL  COST  «$134K* 


ONE 
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Fig.  C-23  Example  of  Completed  Output  Signal 
Matrix  (Range  Function) 
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SIGNAL 

NO. 

SIGNAL 

NOMEN¬ 

CLATURE 

RELATED 

FUNCTION/ 

NAME/ 

NUMBER 

FUNCT  NO. 

CLASS 

ANALOG 

L 

DIGITAL 

DISCRETE 

RF 

VIDEO 

POWER 

MODE 

NAME 

Enom 

Emax 

Emin 

PWR 

OUT 

UNIT 

TOL, 

% 

CONT 
SIGNAL 
NO.  1 

CONT 
SIGNAL  i 
NO.  2 

M400 

TACOUT 

TACCAR 

02 

P 

DC 

TEST 

2.55 

■g 

VOLT 

5 

M340 

M345 

M310 

XMTPLS 

TACCAR 

02 

P 

LPV 

TEST 

10 

VOLT 

5 

M320 

•  M315 

DSCOUT 

TACCAR 

02 

S 

DC 

TEST 

0.5 

VOLT 

N/A 

M320 

M320 

CVSOUT 

TACCAR 

02 

P 

OC 

TEST 

3 

jgH 

VOLT 

5 

M330 

M3 15 

M330 

TACCO 

TACCAR 

02 

P 

DC 

TEST 

3 

1 

VOLT 

5 

M340 

M345 

M340 

SUMC 

TACCAR 

02 

P 

IF 

TEST 

2.55 

VOLT 

N/A 

M350 

M355 

M345 

DIFFC 

TACCAR 

02 

P 

IF 

TEST 

2.55 

1 

VOLT 

N/A 

M350 

M355 

M350 

SUMF 

TACCAR 

02 

P 

IF 

TEST 

2.55 

1 

VOLT 

N/A 

M360 

M365 

M355 

DIFFF 

TACCAR 

02 

P 

IF 

TEST 

2.55 

1 

VOLT 

N/A 

M360 

M365 

M360 

SUMV 

TACCAR 

02 

P 

IF 

TEST 

2.55 

VOLT 

N/A 

M370 

S410 

M365 

DIFFV 

TACCAR 

02 

P 

IF 

TEST 

2.55 

VOLT 

N/A 

M370 

S410 

M3  70 

SUMD 

TACCAR 

02 

P 

ANT 

TEST 

1 

DBM 

N/A 

S400 

M310 

Frp  =  2629  x  10-6  FAILURES/HR 


NOTES: 

(II  SENSOR  DELETED  SINCE  M315  IS  A  SIMPLE  FEEDBACK  WITH  LOW  FAILURE  RATE.  ADEQUATE  FAULT  ISOLATION  EXISTS  WITH  SENSORS  AT  M3 10 

(2)  SENSOR  NOT  REQUIRED  SINCE  PERFORMANCE  MONITOR  SENSOR  FOR  TRANSMITTER  ALREADY  EXISTS  AS  PART  OF  APS-125. 

(3)  WJ  =  «  SINCE  THE  PATH  HAS  INTRINSIC  FAULT  DETECTION  (SEE  PAGE  216) 

d 

•WITHOUT  COSTS  OF  PERFORMANCE  INDICATOR  &  RADAR  SET  CONTROL 

••SINCE  THERE  ARE  FAULT  DETECT  SENSORS  IN  EACH  LRU  WITH  A  RESOLVED  UNCERTAINTY  OF  (1 W-  IS  CALCULATED  USING  EQUATION  NO.  31  j 
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CONT 
SIGNAL 
NO.  1 


PWR  TOL, 

IN  OUT  UNIT  % 


VOLT  5 
VOLT  5 

15  VOLT  N/A 

VOLT  5 
VOLT  5 
VOLT  N/A 
VOLT  N/A 
VOLT  N/A 
VOLT  N/A 
VOLT  N/A 
VOLT  N/A 
-50  DBM  N/A 


■  2629  x  10-6  FAILURES/HR 


Y  V  Y 

Y  Y  Y 

N  Y  N 

Y  Y  Y 

Y  Y  Y 

' 

Y  Y  Y 

Y  Y  Y 

Y  Y  Y 

Y  Y  Y 

Y  Y  Y 

Y  Y  Y 

N  Y  N 


90  )  00  C  5.0  THRESH.  L 

90  3  300  15.0  THRESH.  L 

0  3  300  0  - 


90 

10  C 

6.0 

THRESH. 

L  0.017 

90 

3  300 

5.0 

THRESH. 

L  0.026 

95 

1  C 

5.0 

THRESH. 

L  0.016 

95 

1  C 

5.0 

THRESH. 

L  0.O17 

90 

1  300 

5.0 

THRESH. 

L  0.0A3 

90 

1  300 

5.0 

THRESH. 

L  0.043 

90 

1  300 

8.5 

THRESH. 

L  0.010 

90 

1  300 

8.5 

THRESH. 

L  0.010 

95 

1  300 

0 

N/A 

N/A  00 

SEE  NOTE  (1) 


SEE  NOTE  (2) 


TOTAL  COST  =  S68.0K* 


LT  ISOLATION  EXISTS  WITH  SENSORS  AT  M310  AND  M320. 
KISTS  AS  PART  OF  APS-125. 

IV.  IS  CALCULATED  USING  EQUATION  NO.  31 


Fig.  024  Example  of  Completed  Output  Signal 
Matrix  (TACCAR  Function) 
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APPENDIX  D 

INTERRELATIONSHIPS  BETWEEN  INTERMITTENT 
MALFUNCTIONS  AND  BIT  FALSE  ALARMS,  AND 
SOME  BIT  DESIGN  GUIDELINES  RELATING  TO 
THESE  ISSUES. 
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1.  INTRODUCTION 


Although  current  maintenance  information  systems  do  not  report  any  signif¬ 
icant  information  about  the  frequency  and  maintenance  impact  of  intermittent 
malfunctions ,  it  is  a  well  known  fact  that  this  is  by  far  one  of  the  most  serious 
issues  faced  in  electronic  maintenance.  Experience  indicates  that  such  "inter- 
mittents"  occur  somewhat  less  frequently  than  "hard"  failures,  but  present  such 
extreme  difficulty  of  maintenance  that  their  impact  is  greatly  out  of  proportion  to 
the  frequency  with  which  they  occur.  It  can  be  shown  that  intermittents  con¬ 
tribute  to  the  apparent  frequency  of  BIT  false  alarms.  Some  design  guide¬ 
lines  can  be  suggested  to  deal  with  the  issue  of  BIT  apparent  false  alarms  due 
to  intermittent  system  malfunctions.  Since  these  intermittents  are  true  sys¬ 
tem  failures,  guidelines  leading  to  BIT  capabilities  would  offer  potentially 
major  gains  to  the  efficiency  of  troubleshooting,  while  also  minimizing  the  ap¬ 
parent  frequency  of  BIT  false  alarms.  Discussions  that  follow  define  such 
possibilities  conceptually. 

A  second  issue  in  dealing  with  BIT  false  alarms  arises  because  a  significant 
number  of  electronic  system  failures  do  not  originate  within  any  so-called  "black 
box,"  but  rather  are  caused  by  cable  or  connector  malfunctions.  In  such  cases, 
BIT  will  logically  tend  to  detect  failure  of  those  system  functions  affected,  and 
must  (by  current  design  practice)  necessarily  indicate  a  "black  box"  failure, 
even  though  the  fault  is  indigenous  to  system  cables /connectors.  These  phenom¬ 
ena  therefore  present  a  difficult  maintenance  issue,  because  it  is  literally  possible 
to  change  every  replaceable  unit  in  an  entire  system  without  actually  affecting 
the  fault  symptoms .  Here  again ,  we  have  a  very  old  and  well  known  maintenance 
problem  that  presents  an  issue  in  scoring  the  performance  of  a  given  BIT  con¬ 
figuration  . 

2.  DEFINITIONS  AND  RELATED  EXPLANATORY  DISCUSSION 

INTERMITTENT :  An  electronic  malfunction  which  presents  itself  at  times, 
and  which  does  not  present  itself  at  other  times.  As  a  class,  intermittents  are 
one  of  the  oldest  and  most  difficult  problems  faced  during  electronic  maintenance, 
and  their  impact  outweighs  that  of  the  more  frequently  occurring  "hard"  or 


catastrophic  failure  modes.  Despite  the  fact  that  this  is  universally  known  to 
be  the  case,  there  has  been  little  or  no  effort  to  reduce  the  occurrence  of  in¬ 
termittent? ,  or  to  developing  equipment  and  techniques  to  deal  effectively  with 
them.  Indeed,  the  causes  of  intermittent  malfunction  have  not  even  been  studied 
extensively  in  the  formal  sense.  Thus,  at  the  present  state-of-the-art,  one  of 
the  most  serious  problems  in  electronic  (and  particularly  avionic)  maintenance 
has  been  virtually  ignored  by  the  scientific  community ,  and  maintenance  person¬ 
nel  have  been ,  in  most  cases ,  left  to  fend  for  themselves  when  faced  with  such 
malfunctions . 

BIT  FALSE  ALARM:  The  commonly  accepted  definition  is  any  BIT  failure 
indication  not  confirmed  by  personal  observation,  related  AGE  testing,  or  re¬ 
lated  system  testing.  In  general,  whenever  the  maintenance  process  leads  to  a 
determination  that  a  BIT  alarm  has  occurred,  but  is  not  substantiated  by  related 
system  or  black  box  tests,  the  BIT  indication  will  be  classified  as  a  false  alarm. 
Such  classification  obviously  presumes  that  the  system  or  black  box  tests  are 
infallible,  which  is  hardly  the  case.  Worse  yet,  such  classification  also  tends  to 
presume  that  no  intermittent  condition  caused  the  BIT  to  trigger.  Furthermore, 
such  classification  may  at  times  deny  the  existence  of  cable  and  connector  faults : 
(Q.E.D :  If  all  the  "black  boxes"  test  good,  maintenance  personnel  may  tend  to 
assert  that  a  BIT  alarm  was  "false."  In  such  a  circumstance,  the  system  will 
stubbornly  refuse  to  "work"  no  matter  how  many  black  boxes  are  changed).  In 
terms  of  accurately  evaluating  actual  BIT  performance,  there  needs  to  be 
greater  precision  in  the  classification  of  BIT  indications  as  "false." 

LOSER  BOX :  An  electronic  subassembly  (viz.,  an  LRU)  that  is  removed 
from  its  host  system  for  appar  nt  malfunction,  subsequently  tests  "good"  on 
AGE,  but  is  actually  defective.  The  inability  of  AGE  to  detect  all  possible  UUT 
faults  often  leads  to  this  condiiion.  At  the  same  time,  it  can  be  shown  that  for 
all  practical  purposes,  AGE  will  never  be  able  to  detect  all  possible  failure 
modes.  At  the  current  state  of  the  maintenance  art,  such  LRUs  tend  to  be  re¬ 
issued  (classified  RFI),  reinstalled  to  fail  again  in  the  host  system,  and  repeti¬ 
tively  removed  to  be  once  more  retested  "good."  There  are  no  formal  procedures 
for  dealing  with  this  problem,  so  it  continues  indefinitely  until  some  maintenance 
technician  exercises  the  initiative  necessary  to  recognize  that  a  fault  is  present 
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whether  or  not  the  AGE  so  indicates.  Such  initiative  mu;,  break  the  endless 
loop  of  removal/testing/replacement  /removal ,  but  forces  the  maintenance  person¬ 
nel  to  either  send  the  unit  to  Depot  (to  get  rid  of  it)  or  employ  "ad  hoc"  trouble¬ 
shooting  procedures  in  an  effort  to  identify  and  isolate  the  actual  fault.  It 
must  also  be  noted  that  AGE  and  test  design  provides  no  inherent  means  to 
perform  ad  hoc  tests,  that  T.O.s  generally  provide  no  guidance  in  their  execu¬ 
tion,  and  that  military  regulations  discourage  such  personnel  initiatives.  In  at 
least  one  case  where  a  controlled  maintenance  experiment  was  carried  out  on 
Grumman  aircraft  in  production  and  flight  test ,  three  such  Loser  Boxes  ac¬ 
counted  for  approximately  50%  of  all  the  approximately  200  malfunctions  observed 
in  a  fleet  of  24  aircraft  over  a  period  of  several  weeks.  When  these  units  were 
taken  aside  and  accurately  diagnosed /isolated ,  the  apparent  MTBF  of  their  host 
system  actually  doubled.  In  military  field  maintenance,  where  facilities, 
engineering  personnel,  procedures,  and  authority  to  deal  with  this  problem  are 
not  present,  we  may  infer  that  the  Loser  Box  issue  is  of  major  import.  To  the 
degree  that  BIT  detects  such  problems,  it  would  appear  to  offer  significant 
benefits.  However,  under  present  procedures,  most  such  BIT  alarms  will  tend 
to  be  classified  as  "false." 

3.  CAUSES  OF  INTERMITTENTS 

Although  the  cause  of  every  intermittent  is  a  true  failure  of  some  compo¬ 
nent  or  electrical  parameter,  it  is  the  time-related  and  seemingly  random  nature 
of  the  intermittent  which  makes  it  difficult  to  troubleshoot.  Experience  shows 
that  close  investigation  will  reveal  the  intermittent  malfunction  to  be  introduced 
by  one  or  more  of  the  following: 

Heat,  or  Changes  in  Temperature:  As  a  system  warms  up  or  cools  off,  the 
coefficient  of  material  expansion  causes  minor  stresses  or  mechanical  disloca¬ 
tions.  In  the  presence  of  a  "loose  joint"  or  "loose  connection,"  this  will  often 
lead  to  malfunctions  of  a  transient  nature.  In  addition  to  the  purely  mechanical 
effects  of  heat ,  there  is  also  a  slight  but  well  known  effect  on  the  electrical 
constants  of  component  performance.  Resistors  change  resistance,  capacitors 
change  capacitance,  inductors  change  inductance,  and,  in  particular,  tran¬ 
sistors  change  gain.  A  component  of  marginal  initial  value  may  change  value  due 


244 


to  temperature  variation  to  the  point  where  it  and  its  associated  circuit  are 
normal  at  some  times,  and  fail  at  other  times. 

Shock,  Vibration,  and  G-Load:  Under  varying  values  of  these  forces, 
loose  components  and  loose  connections  often  fail  temporarily.  A  wire  may  at 
times  touch  an  adjacent  point  in  the  circuit,  a  loose  connector  pin  may  not  al¬ 
ways  make  contact,  or  even  a  loose  screw  may  rattle  around  inside  an  assembly, 
causing  all  manner  of  electrical  havoc,  but  not  necessarily  leaving  any  evidence 
of  its  effects  once  the  system  comes  to  rest  after  flight. 

Moisture :  Condensation  of  moisture  vapor  when  a  "warm"  system  cools  off 
in  moist  ambient  air  has  been  known  to  cause  intermittent  malfunctions  along 
with  more  permanent  damage  such  as  corrosion  or  moisture-induced  catastrophic 
failure . 

Acoustic  Effects:  High  ambient  noise  levels  have  an  effect  similar  to  that 
discussed  under  the  heading  of  shock,  vibration,  and  G-load. 

Altitude  or  Pressure  Changes:  These  have  an  effect  similar  to  shock, 
vibration,  and  G-forces,  and  may  also  increase  the  effects  of  moisture  by  caus¬ 
ing  physical  vapor  penetration  of  joints  or  seals. 

Electrical  Transient  Phenomena:  Whenever  the  prime  power  to  a  system  is 
shared  with  other  loads  that  present  EMI  transients,  or  step  functions  in  prime 
power  load ,  intermittent  electronic  failures  often  result .  Again  as  a  matter  of 
experience,  this  may  be  the  most  frequent  cause  of  intermittent  failure. 

Marginal  Components  Operating  Under  Voltage  Variations:  Whenever  a  sys¬ 
tem  has  one  or  more  marginal  components,  normal  (e.g.,  within  tolerance)  vari¬ 
ations  in  power  supply  potentials  may  lead  to  intermittent  failures. 

From  the  above  summarized  list  of  "causes"  it  should  be  apparent  that  an 
intermittent  results  from  the  temporal  application  of  one  or  more  such  forces,  in 
such  a  manner  as  to  increase  the  impact  of  some  inherent  physical  or  electrical 
defect  in  the  equipment.  Since  a  non-existent  fault  can  not  be  detected  or  iso¬ 
lated,  conventional  AGE  tests  are  powerless  to  resolve  such  problems  unless 
chance  causes  the  intermittent  failure  to  occur  during  the  time  of  test. 


From  the  above  casual  definition ,  it  follows  that  fault  isolation  of  an  inter¬ 
mittent  is  a  matter  of  chance  unless  maintenance  personnel  take  measures  to  in¬ 
duce  its  symptoms.  Although  most  current  military  maintenance  processes  do 
not  embody  this  approach,  it  is  useful  to  note  that  commercial  electronic  mainte¬ 
nance  often  has  resort  to  such  measures  as: 

•  Heat  guns  and  localised  freon  cold  sprays 

•  Component-tapping,  or  even  manual  pounding  on  an  assembly,  to  induce 
shock 

•  Deliberate  temporary  minor  misadjustment  of  power  supply  voltages  to 
accentuate  the  effects  of  marginal  component  performance. 

4.  POTENTIALS  OF  BIT  IN  DEALING  WITH  INTERMITTENTS 

.BIT  has  the  inherent  advantage  of  being  a  part  of  the  host  system,  and 
therefore  able  to  observe  intermittent  phenomena  as  they  occur,  rather  than 
after  the  fact.  Furthermore,  since  most  BIT  implementations  provide  parallel 
observation  of  a  number  of  system  signals,  this  offers  the  chance  to  evaluate  the 
significance  of  time-parallel  failure  events  to  see  if  they  are  related.  Also,  be¬ 
cause  BIT  is  indigenous  to  the  host  system,  it  offers  the  potential  of  being 
theoretically  capable  of  detecting  system  faults  not  localized  to  a  "black  box." 
Thus,  in  the  theoretical  sense,  BIT  ought  to  be  considered  as  a  means  to  reduce 
the  severity  of  the  problems  discussed  earlier.  It  should  not  be  regarded  as  a 
panacea  in  these  respects,  but  merely  as  a  way  of  partially  solving  the  problems 
at  issue.  Since  these  are  the  most  significant  problems  faced  in  the  day-to-day 
realities  of  electronic  maintenance ,  any  solution ,  i  ven  a  partial  one ,  would  be  of 
very  significant  logistic  value. 

At  the  same  time,  it  must  be  recognized  that  the  effective  application  of 
BIT  to  these  problems,  to  whatever  degree,- depends  on  improvements  to  the 
judgmental  process  which  presently  classifies  "false  alarms."  So  long  as  real 
alarms  are  inadvertently  classified  as  false,  BIT  will  be  criticized  rather  than 
used  to  maximum  advantage.  The  most  creative  applications  of  BIT  to  the  prob¬ 
lems  that  have  been  discussed  would  meet  with  little  or  no  success  so  long  as  the 
users  refuse  to  believe  the  indicated  results.  Since  neither  AGE  tests,  personal 
observations,  or  BIT  can  ever  be  expected  to  reach  states  of  absolute  perfection, 


there  will  be  no  absolute  reference  to  use  in  judging  the  veracity  of  conflicting 
failure  indications  from  different  test  sources.  What  is  needed  is  an  objective, 
thorough,  and  scientific  procedure  to  be  used  in  investigating  and  properly 
classifying  each  such  conflict. 

Universal  guidelines  cannot  be  suggested  at  the  present  state-of-the-art. 
What  is  needed  is  a  realistic  understanding  of  the  issues ,  and  a  creative  ap¬ 
proach  to  designing  BIT.  To  date,  most  BIT  designs  have  addressed  only 
"hard"  failure  modes.  Design  requirements  should  be  expanded  to  provide  some 
degree  of  consideration  to  intermittent  and  non-system-indigenous  failures. 

Some  initial  suggestions  along  these  lines  follow.  It  is  not  suggested  that  the 
measures  given  be  applied  categorically  to  every  BIT  design,  but' only  that  these 
concepts  and  others  should  be  considered: 

•  Monitor  prime  system  power  for  nominal  voltage ,  frequency ,  and  phase 
angles,  with  a  relatively  simple  and  reliable  electronic  package  capable 
of  detecting  steady  state  and  transient  power  phenomena.  When  other 
BIT  indicators  in  a  system  indicate  transient  failure,  the  power  monitor 
unit  would  tend  to  identify  those  cases  where  power  or  EMI  phenomena 
were  at  fault,  because  both  the  power  and  system  BIT  would  trigger  in 
temporal  proximity.  A  variation  of  this  approach  would  use  "and"  func¬ 
tions  to  inhibit  a  BIT  signal  failure  indication  when  power  problems  were 
coincidentally  detected.  One  such  power  indicator  unit  might  suffice 
for  an  entire  vehicle  or  system 

•  Apply  the  same  philosophy  as  above,  but  monitor  the  characteristics  of 
DC  power  within  each  subsystem.  Again,  this  would  identify  the  tem¬ 
poral  correlation  or  non-correlation  between  signal  failures  and  power 
failures,  either  transient  or  "hard" 

•  Design  BIT  to  evalute  the  sequential  occurrence  of  failure,  rather  than 
just  the  combinational  occurrence  of  fail  indications.  For  example,  in 
cases  where  two  conflicting  BIT  indications  might  lead  maintenance  per¬ 
sonnel  to  conclude  that  an  impossible  system  failure  had  occurred,  the 
sequential  detection  of  symptoms  might  lead  to  an  exactly  opposite  and 
very  useful  set  of  information 
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•  Design  BIT  to  indicate  cable /harness  failure  and  localize  it  to  a  non-LRU 
portion  of  a  system.  For  example,  where  an  LRU  has  BIT  on  an  output, 
consider  putting  BIT  on  the  input  to  the  next  LRU  receiving  that  signal. 
If  the  "copper  path"  between  LRUs  were  to  open,  the  first  BIT  indicator 
would  then  show  the  "signal  good"  indication,  while  the  second  would 
indicate  a  "signal  bad"  conclusion.  These  two  conflicting  observations 
would  tend  to  define  a  "false  alarm"  under  existing  maintenance 
practices.  In  fact,  such  a  BIT  capability  would  in  this  case  be  defin¬ 
itive  of  a  "bad  harness  or  connector"  in  the  system,  but  not  in  any  one 
LRU 

•  Consider  using  BIT  to  generate  marginal  electronic  stimuli  and  thereby 
accentuate  the  detection  of  intermittents  resulting  from  marginal  compo¬ 
nent  constants  or  gain.  There  are  many  precedents  for  testing  systems 
at  reduced  voltage  supply  levels,  or  reduced  signal  levels,  to  identify 
circuits  tending  to  fail  intermittently  as  a  function  of  marginal  perfor¬ 
mance 

•  Consider  designing  BIT  to  simulate  the  dynamic  stimuli  of  flight  when  a 
system  is  on  the  ground.  In  some  cases  this  is  simple  to  accomplish,  and 
in  other  cases  it  is  difficult  or  impossible.  However,  the  "simple" 
implementations  are  often  effective  in  making  flight  symptoms  reproduc¬ 
ible  on  the  ground.  For  example,  accelerometers  or  rate  gyro  assemblies 
can  often  be  designed  to  generate  sample  stimuli  very  inexpensively, 
thereby  permitting  flight  symptoms  to  be  approximated  at  rest 

•  Keep  accurate  maintenance  records  for  each  LRU,  by  serial  number. 

When  an  individual  LRU  is  removed  from  one  or  more  host  systems  for  the 
same  apparent  cause,  but  tested  "good"  on  AGE  more  than  once,  recog¬ 
nize  that  there  is  a  high  probability  that  the  LRU  is  "bad"  and  the  AGE 
cannot  detect  the  fault.  Remove  such  LRUs  to  a  maintenance  level  with 
adequate  diagnostic  skills  and  equipment,  and  require  that  they  not  be 
classified  "RFI"  until  the  cause  has  been  positively  identified  and  cor¬ 
rected  . 
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•  Conceivably,  as  a  corollary  to  the  above,  BIT  could  be  designed  not  to 
just  indicate  "fault  number  XXX,"  but  additionally  to  show  "same  fault 
as  last  time."  This  would  preclude  continued  O-Level  reinstallation  of 
a  "bad"  LRU  which  the  GSE  indicates  to  be  "good" 

•  In  designing  BIT,  be  prepared  to  trade  off  rapid  test  execution  in  favor 
of  thorough  testing.  For  example,  a  quick  '  memory  cruncher"  diag¬ 
nostic,  executed  one  time,  may  show  a  "good"  conclusion.  The  same 
diagnostic,  executed  500  times  may  show  a  parity  problem.  The  slower 
test  will  lead  to  greater  system  readiness,  and  less  maintenance  work¬ 
load,  to  the  degree  that  it  detects  faults  otherwise  missed. 

5.  SUMMARY 

•  By  applying  logic  to  maintenance  experience,  there  is  reason  to  suspect 
that  many  "false  alarms”  are  not  false  at  all 

•  A  significant  subset  of  the  "not-false-false  alarms"  would  be  expected  to 
relate  to  system  intermittents  and/or  non-LRU -indigenous  failures  of 
harness,  cables,  or  power.  These  have  historically  been  among  the 
most  severe  maintenance  problems  in  day-to-day  military  and  commerical 
electronic  maintenance 

•  Extend  the  goals  of  BIT  design  and  optimization  to  encompass  intermit¬ 
tents.  To  the  degree  that  this  is  dene,  benefits  could  be  out  of  propor¬ 
tion  to  the  frequency  with  which  sue  i  faults  occur.  The  BIT  false  alarm 
rate  would  tend  to  decrease.  The  ab  lity  of  BiT  to  highlight  the  causes 
of  severe  maintenance  dificulty  would  increase 

•  Creative  design  will  be  required  if  the  false  alarm  syndrome  is  to  be 
turned  into  an  opportunity  to  minimize  the  most  severe  kinds  of  main¬ 
tenance  actions.  BIT  designers  must  be  encouraged  to  apply  themselves 
to  failures  of  "non-hard"  character 

•  Devise  means  to  get  "Loser  Boxes"  out  of  the  normal  maintenance  cycle, 
and  subject  them  to  in-depth  special  troubleshooting  processes  by  highly 
qualified  personnel.  Require  that  a  "Loser"  remain  in  this  category 
until  its  fault  has  been  identified  and  repaired  with  absolute  certainty. 
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MISSION 

of 

Rome  Air  Development  Center 

RA VC  plan*  and  execute*  research,  development,  test  and 
selected  acquisition  program  in  support  o£  Command,  Control 
Comtmications  and  Intelligence  (C3I)  activities.  Technical 
and  engineering  support  uithin  areas  o&  technical  competence 
is  provided  to  ESV  Program  0{ faces  IPOs)  and  othex  ESP 
elements.  The  principal  technical  mission  axeas  axe 
communications,  electromagnetic  guidance  and  contxol,  sux- 
veillance  o<$  gxound  and  aexospace  objects,  intelligence  data 
collection  and  handling,  information  system  technology, 
ionospheric  propagation,  solid  state  sciences,  micxomve 
physics  and  electronic,  reliability,  maintainability  and 
compatibility. 


